W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2008

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

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Tue, 13 May 2008 23:45:47 +0200
To: Jamie Lokier <jamie@shareable.org>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1210715147.3675.35.camel@henriknordstrom.net>

On tis, 2008-05-13 at 18:44 +0100, Jamie Lokier wrote:

> If this is intended, it definitely needs clarification.
>   1. I had no idea this was intended, despite reading the RFCs.

It's there, but somewhat conflicting and inconsistent.

p6 3.1 Cache Correctness

3.  It is an appropriate 304 (Not Modified), 305 (Use Proxy), or
       error (4xx or 5xx) response message.

   If the cache can not communicate with the origin server, then a
   correct cache SHOULD respond as above if the response can be
   correctly served from the cache; if not it MUST return an error or
   warning indicating that there was a communication failure.

5xx should not be in point 3 there, as 504 is "can not communicate", and
semantically any 5xx is "can not communicate/service this request".

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

Squid does.

What the stale-if-error extension adds to Squid is bounds, limiting when
this may happen.

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

Which is one application for the proposed extension.

Received on Tuesday, 13 May 2008 21:46:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:45 UTC