Re: Old story, a postscript

[Antone Roundy <antone@xxxxxxxxxxxxxx>]

> > > <link rel="service.error"
> > >  type="application/x.atom+xml"
> > >  href="URI for Posting Errors goes here" />
> >
> > I like this.  Want to write up a Pace? -Tim
>
> what gets posted there? a full atom entry describing the error, or is 
> it
> just a hit which is meant to register as an 404?

I strongly favor defining SOMETHING more than simply having a 404 
appear in the server logs.  A few reasons:

1) Atom server's should be able to handle the reporting of the errors 
more intelligently than simply having the errors dumped into the server 
log.  They shouldn't have to be able to parse the server's logs (which 
could be in a non-standard custom format) to figure out whether any 
complaints are coming in about the feeds.

2) It could be useful to have a standard way to indicate what the 
problem was (illegal character, mismatched tags, etc.)

3) If your server has a large custom 404 page, you're going to waste 
bandwidth sending it to people who will never see it.  Better to have 
something at the indicated URI that sends back only useful data or 
something very short.

4) Checking for a non-existent document is a (small) waste of the 
server's time.

5) Just recording a 404 feels sloppy.

Whether the result should be a full Atom entry or something different 
would be good to discuss.  The following information could be useful:

1) The URI of the feed with the error
2) What the error was
3) The query time when the feed was fetched (this wouldn't be entirely 
reliable, because the client's clock may not be set correctly, so the 
time when the error report came in could be useful), or the update time 
for the feed (as reported by the feed itself...except that if parsing 
fails, the client may not know this).

***** One reason why this information would be important is that if 
someone caches a feed, loads it again later, and reports an error that 
has already been fixed, it would be good to be able to figure that out. 
 We might want to recommend not reporting errors when loading feeds 
from local storage, but even that wouldn't solve the problem, because 
you could be loading a cached feed off of a server other than the one 
that published it.  Boy, this opens up a whole new can of worms.  We 
might want to recommend/require not reporting errors unless the feed is 
loaded from the server indicated in @href.  This would also protect 
against DDoSs which might be perpetrated by posting broken feeds with 
someone else's address in @href.

4) The user agent reporting the error (could come from the HTTP headers)

Anything else?

Antone