W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2009

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

From: Brian Smith <brian@briansmith.org>
Date: Thu, 22 Oct 2009 00:31:05 -0500
To: "'Mark Nottingham'" <mnot@mnot.net>
Cc: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-ID: <000301ca52d8$dcd01b40$967051c0$@org>
Mark Nottingham wrote:
> On 14/10/2009, at 6:38 PM, Brian Smith wrote:
> > I think that 201 and 304 responses cannot be stored in cache, ever,
> > because
> > they use the ETag header for a different purpose than for supporting
> > conditional GET, so you cannot validate them with the origin server.
> >
> > Similarly, does it make sense to cache 405 Method Not Allowed
> > responses to
> > POST requests, so that they could be returned for a subsequent GET
> > request?
> > Similarly, POST responses 411 Length Required, 413 Request Entity
> > Too Large,
> > and 415 Unsupported Media Type responses subsequent GET requests.
> >
> > Also, 417 Expectation Failed is basically a "hop-by-hop status code"
> > since it only makes sense when an unsupported value for a hop-by-hop
> > request header field is provided by the cache to the server.
> I think I agree. I believe 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
> Note that (b) includes such responses even if they don't actually have
> heuristic freshness applied to them; in this manner, a cache can still
> store a 200 response with no Expires or CC: max-age (for example).
> Effectively, then, the list of status codes that are cacheable is
> derived from the list of those that allow heuristic freshness to be
> used, with the proviso that other status codes can explicitly state
> their store-ability.
> Does this make sense?

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.

>   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 available
> WRT #1, I think they can, because a cache may want to use that stale
> representation as the basis of revalidation in the future.

I agree.

> 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
    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).

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.

Received on Thursday, 22 October 2009 05:31:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:52 UTC