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

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.

Received on Wednesday, 11 November 2009 19:32:24 UTC