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

From: Mark Nottingham <[email-masked]>
Date: Tue, 3 Nov 2009 13:39:27 -0800

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/

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 3 Nov 2009 22:27:48 -0600

> a cache doesn't understand the 206 status code, it can't be cached.

For 206, is it really the status code that changes the caching behavior, or
is it the presence of the Content-Range header in the response? AFAICT, it
would be clearer to replace all the requirements in P5 & P6 specifically
mentioning 206 responses with statements "any response with a Content-Range
header."

Actually, what is the difference between a 200 response with a Content-Range
and a 206 response with a Content-Range? The 206 status code seems to mean
200 + "whoa, look out, there's probably a Content-Range header." But,
there's no prohibition against using Content-Range with other status codes
(especially extension status codes).

Regards,
Brian

---

From: Nicolas Alvarez <[email-masked]>
Date: Wed, 11 Nov 2009 16:31:26 -0300

Brian Smith wrote:
> Mark Nottingham wrote:
>> On 14/10/2009, at 6:38 PM, Brian Smith wrote:
>> WRT #2, I think they should be able to, despite the text you quote:
>> 
>> > Finally, note the following statement in Part 2, Section 4: "However,
>> > applications MUST understand the class of any status code, as
>> > indicated by the first digit, and treat any unrecognized response
>> > as being equivalent to the x00 status code of that class, with the
>> > exception that an unrecognized response MUST NOT be cached." Here,
>> > I think "MUST NOT be cached" means specifically "MUST NOT be
>> > stored in caches." I think Part 6 should mention
>> > this requirement explicitly.
>> 
>> because there's no reason that a cache has to understand the status
>> code, as long as the cache directives are explicit.
> 
> To see why that doesn't work, consider four hypothetical extension status
> codes:
>   
>     281, defined to mean the same as 201
>     286, defined to mean the same as 206
>     384, defined to mean the same as 304
>     497, defined to mean the same as 417

Another code to keep in mind in this discussion is 226, defined in RFC3229.

Quote RFC3229 section 5.5:

   Although we are not aware of any HTTP/1.1 proxy implementations that
   would attempt to cache a response with an unknown 2xx status code,
   the HTTP/1.1 specification does allow this behavior if the response
   carries an Expires or Cache-Control header field that explicitly
   allows caching.  This would present a problem when a 226 (IM Used)
   response carries such headers.

   The solution in that case is to exploit the Cache Control Extensions
   mechanism from the HTTP/1.1 specification.  We define a new cache-
   directive, "im", which indicates that the "no-store" cache-directive
   may be ignored by implementations that conform to the specification
   for the IM and A-IM headers.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 20 Nov 2009 11:25:45 +1100

[ 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.
> 
> 
> 
>>> shouldn't be including the Cache-Control/Expires headers in its response. I
>>> 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
>> 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?
>> 
>> --

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 20 Nov 2009 20:09:29 +0100

mån 2009-10-12 klockan 20:22 -0500 skrev Brian Smith:
> What, precisely, must the Cache-Control or Expires header fields contain in
> order to make a response to a POST, a 302 response, a 303 response, or a 307
> response cacheable? This seems to not be specified anywhere in the
> specification.

For responses to GET/HEAD it means that heuristic freshness calculation
is not allowed, only explicit freshness indication via Cache-Control or
Expires.

If Cache-Control max-age / s-maxage or Expires is present and no other
directives prevent caching then the response is cacheable.

POST (and other non-GET methods) is a bit different.. cache model is a
bit different for non-GET methods. Not even sure there is even a
beginning of a consensus on what the cache model for non-GET methods
would be. (except for HEAD which is GET with a slight twist)

Regards
Henrik