W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

Re: Warnings and SHOULD

From: Willy Tarreau <w@1wt.eu>
Date: Sun, 17 Jul 2011 07:43:15 +0200
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20110717054315.GB31226@1wt.eu>
Hi Mark,

On Sun, Jul 17, 2011 at 11:52:48AM +1000, Mark Nottingham wrote:
> Our text on Warnings <http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-15#section-3.6> currently includes the following requirements:
> """
>    110 Response is stale
>       A cache SHOULD include this whenever the returned response is
>       stale.
>    111 Revalidation failed
>       A cache SHOULD include this when returning a stale response
>       because an attempt to validate the response failed, due to an
>       inability to reach the server.
>    112 Disconnected operation
>       A cache SHOULD b include this if it is intentionally disconnected
>       from the rest of the network for a period of time.
>    113 Heuristic expiration
>       A cache SHOULD include this if it heuristically chose a freshness
>       lifetime greater than 24 hours and the response's age is greater
>       than 24 hours.
> """
> (yes, there's a typo)
> ... along with a corresponding requirement in <http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-15#section-2.3.3>:
> """
>    A cache SHOULD append a Warning header field with the 110 warn-code
>    (see Section 3.6) to stale responses.  Likewise, a cache SHOULD add
>    the 112 warn-code to stale responses if the cache is disconnected.
> """

I see nothing in the text surrounding these parts which says that these 1xx
responses may only be sent to HTTP/1.1 clients. We should be careful with
this because the first iteration of 1.0 defines 1xx status codes as
"Informational - Not used, but reserved for future use", thus it is likely
that some clients will consider them as final status codes, and possibly
invalid ones. Please note that RFC2616 did not appear to put any such
reservation either.

> I'd observe that the information in 110 and 113 duplicates what a client can already discover from examining the caching headers on the response (Date, Age, Expires, Last-Modified, Cache-Control), so I propose we downgrade these to MAYs (or just change it to prose).
> While we're at it, the semantics of 111 and 112 seem purely advisory, and they're not implemented in clients or caches (at all, AFAIK). So, I'd propose we downgrade them at the same time.

I have little knowledge on caching, but in general I too prefer when we use
"MAY" instead of "SHOULD" for things that nobody implements.

Received on Sunday, 17 July 2011 05:43:55 UTC

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