[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Old story, a postscript


1) The URI of the feed with the error
I think this would be more reliably controlled by the server manipulating
the URI for each feed. All errors can go to the same script, if necessary.
Bill Kearney posted something like

<link rel="service.error"
  type="application/x.atom+xml"
  href="http://example.com/errors?blogid=12345"/>
That makes sense. For one thing, if you're loading a feed from a mirror, the URI you got it from may not mean anything...but then, if we go with my prior suggestion of only reporting errors to the same server you loaded from, those wouldn't be reported anyway.

So the ID of the feed with the error would be a better way to go. If we're sending an XML payload rather than just pinging a URI, I'd still vote for including the ID in the XML (perhaps as well as the URI, at the publisher's option, in case they just want to record the URI and ignore the XML, which would be the case for anyone who doesn't have a script sitting there to record errors--it just goes into their server log).

2) What the error was
OK, but in a standard format and/or just a text description? I'm trying to
think of a way to transmit an optimal amount of info while minimizing spam
usefulness.
I'd vote for coming up with a set of error numbers for different types of things rather than using text descriptions--partly for size, partly for language issues, partly for ease of summarizing what errors have been reported. Perhaps text could be included too, as is done with HTTP status codes. There could be a number for "other" errors in case something unexpected happens. But I think there would be just a few classes of error that would cover almost every case: character not in the character set, mismatched tags, attributes missing opening or closing quote marks (or even an equals sign), unknown entity, unknown element (perhaps that should be ignored--certainly if it's in a namespace other than atom and the client simply doesn't know about that namespace), no xml text declaration (or whatever <?xml ... ?> is called...which would occur long before you got to the error service URI, so would you even look for it?).

4) The user agent reporting the error (could come from the HTTP headers)
I don't think we should duplicate any HTTP header.
Agreed. No point doing that.

Somebody's email had a URI with a line number in it. That sounds good too...though of course, as soon as another entry gets added to the feed, the line number will change. Still, till that happens, it could be useful.