On 02/06/2009, at 5:04 PM, Brian Smith wrote: > 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. 2616 already states that a POST response can only be cached if there's explicit freshness information. > 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). That requirement is placed upon the POST, not a subsequent GET. > Still, I expect that almost all caches will continue to avoid > caching any > POST responses, just to avoid the issue altogether Very possibly; for the foreseeable future, I think using POST in this manner is a fairly specialised thing. However, it's also useful in a number of cases (esp. as "RESTful" Web Services become more prevalent). Cheers, -- Mark Nottingham http://www.mnot.net/Received on Wednesday, 3 June 2009 07:48:23 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:19 UTC