Re: Old story, a postscript

[Robert Sayre <mint@xxxxxxxxxxxxxxx>]

On 4/28/04 9:18 PM, "Antone Roundy" <antone@xxxxxxxxxxxxxx> wrote:

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

Agreed. Although the server can do anything it wants (including nothing)
with the posted content. Besides, the UA should receive status 200 for a
successful POST.

> 
> 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

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"/>

> 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. 

> 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).

I think "wouldn't be entirely reliable" is an understatement. The server
could infer the report's usefulness based on the last successful GET of the
feed from the same IP... well, maybe the Internet is too broken for this
one.
 
> ***** 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.

People have this kind of problem with the web all the time ("clear your
cache"). I think Atom can live with it, too.

> 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.

Sure does. But I kind of like the consequence you're describing.

You published an invalid feed, and people are still reading it, even though
it's since been fixed on the server. It reflects the truth of the matter.
 
> 4) The user agent reporting the error (could come from the HTTP headers)

I don't think we should duplicate any HTTP header.
 
Robert Sayre