Subject: Warnings and SHOULD

From: Mark Nottingham <[email-masked]>
Date: Sun, 17 Jul 2011 11:52:48 +1000

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/

---

From: Robert Collins <[email-masked]>
Date: Sun, 17 Jul 2011 14:49:53 +1200

On Sun, Jul 17, 2011 at 1:52 PM, Mark Nottingham <[email-masked]> wrote:
>      A cache SHOULD include this if it is intentionally disconnected

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).

> This would allow us to remove the text in 2.3.3, or just turn it into an informative reference.

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

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 17 Jul 2011 12:54:50 +1000

> (squid implements 113 FWIW).

If a heuristic was applied, there won't be any headers for explicit freshness.

The semantics of 112 can't be determined solely by looking at the response (although if it had explicit freshness and was served stale, it's a big hint). I just don't think we need a SHOULD enforcing something that's advisory (and not implemented).

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 17 Jul 2011 07:43:15 +0200

Hi Mark,

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

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

Regards,
Willy

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 17 Jul 2011 21:41:32 +1200

On 17/07/11 14:49, Robert Collins wrote:
> On Sun, Jul 17, 2011 at 1:52 PM, Mark Nottingham<[email-masked]>  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
>>
>> ... along with a corresponding requirement in<http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-15#section-2.3.3>:
>>
>> """

111 is already implemented by Squid-3. I'm not sure if it occurs in all 
the useful cases yet though.

112 is not, though we may benefit from being able to distinguish 
offline_mode admin caused problems from the undesirable 111 events.

AYJ

---

From: "Moore, Jonathan (CIM)" <[email-masked]>
Date: Sun, 17 Jul 2011 11:28:27 +0000

The client-side cache in Apache HttpComponents HttpClient implements all of these warnings, for what it's worth. 

I still need to consider the rest of the proposal but wanted to at least correct the "nobody implements" assertion. 

Thanks,
Jon
........
Jon Moore

On Jul 17, 2011, at 5:43 AM, "Amos Jeffries" <[email-masked]> wrote:

> 111 is already implemented by Squid-3. I'm not sure if it occurs in all the useful cases yet though.
> 
> 112 is not, though we may benefit from being able to distinguish offline_mode admin caused problems from the undesirable 111 events.
> 
> AYJ
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 19 Jul 2011 20:41:16 +1000

Hi Willy,

> invalid ones. Please note that RFC2616 did not appear to put any such

We're talking about warn-codes here, not status codes...

Cheers,

---

From: "Moore, Jonathan (CIM)" <[email-masked]>
Date: Thu, 21 Jul 2011 13:41:38 +0000

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" <[email-masked]> 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
>
>... along with a corresponding requirement in
><http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-15#section-2.3.3>:
>
>"""
>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.
>