Subject: Re: What are "appropriate Cache-Control or Expires header fields"

From: Mark Nottingham <[email-masked]>
Date: Wed, 3 Mar 2010 16:47:23 +1100

I haven't heard any more feedback about this. AFAICT the only thing remaining in this issue <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/199> is to adjust the language in p2-semantics that originally brought this up.

I think we should:

1) Remove all reference to caching from the status code definitions in p2 (e.g., most of the 3xx, 410), relying on it to be covered by p6, and
2) Move the text that associates heuristic freshness with individual status codes out of p6 into the appropriate status code definitions in p2, and
3) Allow future status codes to identify themselves as allowing heuristic freshness (the current requirement in p6 is IMO too strict of a reading of 2616, looking at it again).

Thoughts?

On 29/12/2009, at 8:23 PM, Mark Nottingham wrote:

> Making some progress here:
>  http://trac.tools.ietf.org/wg/httpbis/trac/changeset/737
> 
> 
> On 20/11/2009, at 11:25 AM, Mark Nottingham wrote:
> 
>> [ sorry, I thought I sent this out quite some time ago. ]
>> 
>> I've been thinking about this more, and trying to make the spec changes. 
>> 
>> I'm now at a place where it looks like the most minimal thing we can do to clarify this (vs. 2616) is:
>> - unknown / unimplemented status codes are not cacheable (e.g., 206 when appropriate)
>> - responses that have explicit freshness are cacheable
>> - status codes that explicitly allow heuristic freshness are cacheable
>> 
>> Otherwise, we're going to have to make a determination regarding the cacheability of every status code, and some of them are going to be difficult.
>> 
>> It's true that going in the direction outlined above will allow people to assign cacheability to things where it doesn't make sense, but I'd argue that a) this isn't a real interop problem now, and b) if this is the case, what we should do is raise a separate issue (e.g., "404 responses should not be cacheable"), so that we can be sure we don't break current implementations.
>> 
>> 
>> 
>> On 03/11/2009, at 1:39 PM, Mark Nottingham wrote:
>> 
>>> Roy pointed out in conversation that 206 is most relevant  here; it changes the interpretation of a response fundamentally.  I.e., it's legitimate for a 206 to have directives that make it cacheable, but if a cache doesn't understand the 206 status code, it can't be cached.
>>> 
>>> As such, it seems like there's already a precedent; a cache has to understand the status code, as Brian points out.
>>> 
>>> So, it looks like (c)...
>>> 
>>> I've created <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/199> to track this. Unless I see any disagreement, I'll start incorporating (c) into the next draft.
>>> 
>>> 
>>> 
>>> On 22/10/2009, at 4:30 PM, Mark Nottingham wrote:
>>> 
>>>> 
>>>> On 23/10/2009, at 2:20 AM, Brian Smith wrote:
>>>> 
>>>>> If it doesn't make sense to cache a response, then the origin server
>>>>> shouldn't be including the Cache-Control/Expires headers in its response. I
>>>>> think that's your position and I totally agree with that.
>>>> 
>>>> Yes.
>>>> 
>>>>> But, it seems
>>>>> strange to me to say a cache may cache anything with a Cache-Control header
>>>>> as-is--EXCEPT it must treat 201, 206, 304, 417 (and probably a few more
>>>>> 4xx/5xx errors) specially, but that's it, no new special cases, ever.
>>>> 
>>>> 
>>>> Right. If we follow this path, there are roughly three options;
>>>> 
>>>> a) Make exceptions for 201, etc. and no more
>>>> b) Don't make exceptions for 201, etc. -- i.e., purposefully allow servers to shoot themselves in the foot here (without promoting it, of course)
>>>> c) Allow new status codes to except them, which takes us back to caches having to understand status codes to store them.
>>>> 
>>>> If we were working from a clean slate, I think (b) is probably the right thing to do. However, we're not -- although adopting (b) won't make any existing caches non-conformant: one could argue that a 201 or a 281 w/ Expires can be cached, thanks to the advice that Expires makes a non-cacheable response cacheable.
>>>> 
>>>> How do people feel about this? Is (b) workable? If not, (a) or (c), or something else?
>>>> 
>>>> --
>>>> Mark Nottingham     http://www.mnot.net/
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Mark Nottingham     http://www.mnot.net/
>>> 
>>> 
>> 
>> 
>> --
>> Mark Nottingham     http://www.mnot.net/
>> 
>> 
> 
> 
> --
> Mark Nottingham     http://www.mnot.net/
> 
> 

--
Mark Nottingham     http://www.mnot.net/

---

From: Brian Smith <[email-masked]>
Date: Mon, 08 Mar 2010 09:33:49 -0600

Mark Nottingham wrote:
> I haven't heard any more feedback about this. AFAICT the only thing remaining in this issue<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/199>  is to adjust the language in p2-semantics that originally brought this up.
>
> I think we should:
>
The change you made in changeset 721 (adding "the response status is 
understood by the cache and defined as being cacheable") was good 
because every cacheable status code would be explicitly marked so. But, 
then changeset 737 made things really unclear--if a status code doesn't 
say anything about its cacheability, then is it cacheable or not? The 
added concept of "understanding" from Changeset 737 could (and should) 
be replaced by simple, explicit statements in the definition of each 
status code stating exactly what a cache is allowed to do with a 
response of that code--for example, "This is a cacheable-if-fresh status 
code" and "This is a heuristically-cacheable status code," and with the 
language in part 6 can be changed to "the status code is defined as 
being cacheable-if-fresh and the cached response is fresh [ref to 
standard freshness definintion], or the status code is defined as being 
hearistically-cacheable and the cached response is fresh according to 
the hueristic freshness calculation [ref to it]." These are the kinds of 
statements that implementors can directly use to create code without any 
potential for misunderstanding or disagreement amonst readers of the spec.

I will spend some time in the next day or two to create a proposal that 
uses this explicit approach if you are open to it.

Regards,
Brian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 9 Mar 2010 20:31:23 +1100

See <http://www.w3.org/mid/[email-masked]>. Defining cacheability for each individual status code is not a simple thing.

On 09/03/2010, at 2:33 AM, Brian Smith wrote:

> The change you made in changeset 721 (adding "the response status is understood by the cache and defined as being cacheable") was good because every cacheable status code would be explicitly marked so. But, then changeset 737 made things really unclear--if a status code doesn't say anything about its cacheability, then is it cacheable or not? The added concept of "understanding" from Changeset 737 could (and should) be replaced by simple, explicit statements in the definition of each status code stating exactly what a cache is allowed to do with a response of that code--for example, "This is a cacheable-if-fresh status code" and "This is a heuristically-cacheable status code," and with the language in part 6 can be changed to "the status code is defined as being cacheable-if-fresh and the cached response is fresh [ref to standard freshness definintion], or the status code is defined as being hearistically-cacheable and the cached response is fresh according to the hueristic freshness calculation [ref to it]." These are the kinds of statements that implementors can directly use to create code without any potential for misunderstanding or disagreement amonst readers of the spec.
> 
> I will spend some time in the next day or two to create a proposal that uses this explicit approach if you are open to it.
> 
> Regards,
> Brian
>