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

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?

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.

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.

Received on Wednesday, 14 October 2009 06:51:44 UTC