Re: Warnings and SHOULD

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 UTC