Re: Warnings and SHOULD

On Sun, Jul 17, 2011 at 1: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 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).

I don't see how they are redundant:
110 depends on cache heuristics
   stale
      A response is stale if its age has passed its freshness lifetime.
->
freshness lifetime
      The length of time between the generation of a response and its
      expiration time.
->
   heuristic expiration time
      An expiration time assigned by a cache when no explicit expiration
      time is available.

113 likewise: if squid determines that a not-modified-for-3-weeks file
does not need refreshing for 30 hours, 25 hours later a client can
determine that the age is (say) 25 hours, but not why - was it due to
disconnected operation? was it a heuristic?

(squid implements 113 FWIW).

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

I'd like to get 111 implemented in squid for front-end acceleration,
as a diagnostic helper for tracking a glitching backend. 112 I don't
have any particular view on.

-Rob

Received on Sunday, 17 July 2011 02:50:26 UTC