Re: I-D Action:draft-nottingham-http-stale-if-error-01.txt

Roy T. Fielding wrote:
> Upon further review, I see no reason for this extension.
> >   In this context, an error is any situation which would result in a
> >   500, 502, 503 or 504 HTTP response status code being returned.
> 
> 5xx errors are intended to authorize client-side workarounds,
> including the delivery of stale content.  That is, in fact, the only
> real difference between 4xx and 5xx codes.  If this needs to be
> clarified in the httpbis drafts, then it should be an issue on
> httpbis.

If this is intended, it definitely needs clarification.

  1. I had no idea this was intended, despite reading the RFCs.

  2. I'm not aware of any clients which do that, suggesting their
     authors didn't think so either.

  3. On the server side, 5xx error codes are often used to indicate
     faults in the server logic (things like couldn't generate a page,
     broken database, etc.) and nearly always _intend_ browsers to
     show users the error page which is sent, and definitely not stale
     content.

  4. What you've said suggests servers should send 4xx error codes for
     conditions like "server unable to generate page when moving
     between forms, here is an error page explaining why you cannot
     proceed right now".  But which 4xx code?  It's not a client error.

> We don't need a cache-control option to authorize what should already be
> authorized by the HTTP status code.

In which case, we either need a cache-control option to _unauthorize_
it, or new 4xx error codes to indicate server faults for which the
client should not substitute stale pages.

-- Jamie

Received on Tuesday, 13 May 2008 17:45:21 UTC