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

Re: Warnings and SHOULD

From: Moore, Jonathan (CIM) <Jonathan_Moore@Comcast.com>
Date: Thu, 21 Jul 2011 13:41:38 +0000
To: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <CA4DA0E0.1A4B3%Jonathan_Moore@Comcast.com>
I'm not sure all the information in these Warnings is actually recoverable
by the client just from examining other headers, especially because a
Warning header includes a warn-agent identifier and hence provides
additional diagnostic information. This is especially useful in a
datacenter setting with layered HTTP components where this type of
staleness might be indicative of a problem.

Furthermore, it is easier for an application to look for the Warning
header than it is to perform and get right all the freshness calculations.
The whole point of having an off-the-shelf HTTP-compliant cache is so that
client applications don't have to do those calculations. ;)

In summary, though, I'm in favor of keeping the SHOULDs.

Jon Moore
Comcast Interactive Media

On 7/16/11 9:52 PM, "Mark Nottingham" <mnot@mnot.net> wrote:

>Our text on Warnings
>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
>   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'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.
>This would allow us to remove the text in 2.3.3, or just turn it into an
>informative reference.
>Mark Nottingham   http://www.mnot.net/
Received on Thursday, 21 July 2011 13:42:13 UTC

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