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

On 22/10/2009, at 4:31 PM, Brian Smith wrote:

> I think Part 6 should be written in a way that is oblivious to any  
> status
> codes except 304 and maybe 206. If a cache isn't aware of the method's
> cacheability, or it isn't aware of the status code's cacheability,  
> then it
> must not cache it; it may only cache responses in accordance with  
> the rules
> explicitly stated in each method definition and status code  
> definition. I
> would specify the heuristic freshness rules this way too. Part 6  
> would then
> only explicitly mention status codes 304 and maybe 206 (though I'd  
> try to
> put all the special handling of 206 into the status code definition).
>
> This way, the definitions of each HTTP-defined method and HTTP-defined
> status code would serve as models for people writing specifications  
> for
> extension methods/status codes.

Makes sense.

>>  1) Whether a response with an Expires in the past (for example) can
>> be stored (as you brought up), and
>>  2) Whether caches that don't understand a status code can still
>> cache it, if it has explicit freshness availabl

[...]

>> 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
>
> A cache that used the same 200/300/400 rule to cache these responses  
> would
> erroneously handle all of these responses. Or, put another way, if you
> removed the "must understand" requirement I quoted above, then no  
> new status
> code could ever have different caching requirements than the  
> default. For
> example, no new status code could ever use the ETag header in the  
> same way
> 201 does, because it would have to use ETag to support validation  
> (note that
> you cannot validate a 201 response with the server).

Remember that I said that...

>> this can be resolved by further
>> constraining what can be stored to things that either:
>>   a) have explicit freshness information present, or
>>   b) are allowed to have heuristic freshness information applied

281 (for example) would only be cached if it had explicit freshness  
available, or its definition allow heuristic freshness *and* the cache  
understands the status code.


> Also, do you want to allow caches to automatically rewrite a "201  
> Created"
> response into a "200 OK" response if the 201 response had
> Content-Location=Request-URI and Cache-Control set appropriately?  
> Because it
> definitely should not return a cached "201 Created" response (from a  
> PATCH,
> POST, or PUT) as-is in response to a subsequent GET.


Huh? Ah, I see -- I'm assuming we'd rewrite the requirement about  
being equivalent with the more general X00 status code to refer to  
these rules WRT caching.



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

Received on Thursday, 22 October 2009 07:16:54 UTC