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

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

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.

Regards,
Brian

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