- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 3 Jun 2009 17:47:46 +1000
- To: Brian Smith <brian@briansmith.org>
- Cc: "'Thomas Broyer'" <t.broyer@gmail.com>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
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