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 10:20:46 -0500
To: "'Mark Nottingham'" <mnot@mnot.net>
Cc: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-ID: <000301ca532b$3b9637c0$b2c2a740$@org>
Mark Nottingham wrote:
> On 22/10/2009, at 4:31 PM, Brian Smith wrote:
> > 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.

To clarify: It doesn't make sense for a cache to ever return a cached 201
response, because 201 means that a resource was created on the origin
server, but the origin server didn't even see the request, so nothing was

It doesn't make sense for a cache to ever return a cached 417 response,
because a 417 response only makes sense when the cache included an Expect
header in its upstream request, and Expect is hop-by-hop.

Those are just two examples. There are quite a few status codes defined
already in the HTTP spec that don't make sense to cache in the default way.
So, I assume that some future status codes will be similar.

If it doesn't make sense to cache a response, then the origin server
shouldn't be including the Cache-Control/Expires headers in its response. I
think that's your position and I totally agree with that. But, it seems
strange to me to say a cache may cache anything with a Cache-Control header
as-is--EXCEPT it must treat 201, 206, 304, 417 (and probably a few more
4xx/5xx errors) specially, but that's it, no new special cases, ever.

Received on Thursday, 22 October 2009 15:21:16 UTC

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