W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Re: draft-ietf-httpbis-p6-cache-06

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


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