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
........
Jon Moore
Comcast Interactive Media






On 7/16/11 9:52 PM, "Mark Nottingham" <mnot@mnot.net> 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'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.
>
>Thoughts?
>
>
>--
>Mark Nottingham   http://www.mnot.net/
>
>
>
>
Received on Thursday, 21 July 2011 13:42:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:45 GMT