- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 23 Oct 2009 10:30:01 +1100
- To: Brian Smith <brian@briansmith.org>
- Cc: "'HTTP Working Group'" <ietf-http-wg@w3.org>
On 23/10/2009, at 2:20 AM, Brian Smith wrote: > 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. Yes. > 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. Right. If we follow this path, there are roughly three options; a) Make exceptions for 201, etc. and no more b) Don't make exceptions for 201, etc. -- i.e., purposefully allow servers to shoot themselves in the foot here (without promoting it, of course) c) Allow new status codes to except them, which takes us back to caches having to understand status codes to store them. If we were working from a clean slate, I think (b) is probably the right thing to do. However, we're not -- although adopting (b) won't make any existing caches non-conformant: one could argue that a 201 or a 281 w/ Expires can be cached, thanks to the advice that Expires makes a non-cacheable response cacheable. How do people feel about this? Is (b) workable? If not, (a) or (c), or something else? -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 22 October 2009 23:30:39 UTC