- From: Brian Smith <brian@briansmith.org>
- Date: Tue, 2 Jun 2009 02:04:13 -0500
- To: "'Mark Nottingham'" <mnot@mnot.net>
- Cc: "'Thomas Broyer'" <t.broyer@gmail.com>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
Mark Nottingham wrote: > On 28/05/2009, at 1:31 AM, Brian Smith wrote: > > Applying Postel's rule, a cache shouldn't return a cached POST > > response to a GET/HEAD request, and servers shouldn't include Cache- > > Control/Expires headers in POST responses. That should be explicit > > in the specification. > > There has been considerable discussion on this, and your conclusion > wasn't suggested AFAIK, nor was it the direction we've chosen to move > in. See: > http://trac.tools.ietf.org/wg/httpbis/trac/ticket/139 > http://www.w3.org/mid/08345F97-7D4D-40AD-98E2- > EF73E93C031F@mnot.net (entire thread) My concern is that there are many origin servers that assume that a POST response will not be returned in response to a subsequent GET/HEAD request--in other words, they assume the method is part of the cache key. But, I can see that my concern is unjustified, since even if a POST response is cached, in cannot be returned in a subsequent request until it has been revalidated (as required by RFC 2616 section 13.10). Since the cache has to do one (possibly conditional) GET after every POST anyway, there is very little chance of any problematic behavior. Still, I expect that almost all caches will continue to avoid caching any POST responses, just to avoid the issue altogether--especially since caching POST responses doesn't reduce the number of requests that need to be forwarded to the origin server at all (because of mandatory revalidation). - Brian
Received on Tuesday, 2 June 2009 07:04:55 UTC