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

Brian Smith wrote:
> Mark Nottingham wrote:
>   
>> POST caching is still a work in progress; p6 now accommodates it, but
>> we haven't yet modified the definition of POST itself. Stay tuned...
>>
>> WRT 302 / 307 / 303 -- the use of the term 'cacheable' is cloudy here,
>> but otherwise it's pretty straightforward; are you just looking for
>> them to reference the header definitions or p6 in general?
>>     
>
> The definition of "cacheable" is precise enough (see the definition in Part
> 6), although it is confusing because "cacheable" doesn't imply that a cache
> may actually store (aka cache) it; the request and response also have to
> meet the requirements in Part 6, Section 2.1 (Response Cacheability).
>
> What I am asking is this: How does a Cache-Control field indicate that an
> otherwise-uncacheable response is cacheable? How does an Expires field
> indicate that an otherwise-cacheable response is cacheable?
>   
Expiry means fresh until, which ties in with freshness part of cache 
philosophy, so Expiry header implies cachability (as long as it is in 
the future).

> If a 302/303/307 response doesn't contain an Expires header or a
> Cache-Control header, then it isn't cacheable. That is clear. But, if the
> response contains *any* Expires header, does that make it cacheable? And, if
> it contains any Cache-Control header, does that make it cacheable? Or, does
> the Cache-Control header have to contain specific values like "public,"
> "s-maxage," "must-revalidate", like is specified in Part 7, Section 3.1?
> And, if so, what are those specific values? The only cache-control directive
> definition that specifically says "cacheable" is "public."
>
> In my implementation, I take the existence of any Cache-Control or Expires
> field in the response makes the response cacheable.
>
>   
what about Cache-control: no-store, no-cache ?

I think you need to look at what the actual directives are.  As for 
Expiry, it has to be in the future (relative to Date), else it is stale.

IOW I think the response needs to be treated the same way as any other 
response in terms of evaluation of cache-control for cacheability.

Difference might be in treatment of cache validators, since I don't know 
if you can have an ETag or Last-Modified on something that has no entity.

For instance, not every 200 response is cacheable either (which I think 
was asserted earlier in this thread).

Regards

Adrien

> Cheers,
> Brian
>
>   
>> On 13/10/2009, at 12:22 PM, Brian Smith wrote:
>>     
>>> 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.
>>>       
>
>
>
>   

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Wednesday, 14 October 2009 07:01:41 UTC