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

Re: #290 [was: SHOULD-level requirements in p6-caching]

From: Roy T. Fielding <fielding@gbiv.com>
Date: Wed, 4 May 2011 19:32:27 -0700
Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <28655785-6F6F-4D20-8AA7-3E0C30EE99F7@gbiv.com>
To: Mark Nottingham <mnot@mnot.net>

On May 4, 2011, at 7:01 PM, Mark Nottingham wrote:

> 
> On 05/05/2011, at 11:37 AM, Roy T. Fielding wrote:
> 
>>> As I've said a few times now, according to the spec, that's currently very clearly equivalent to:
>>> 
>>> GET /foo HTTP/1.1
>>> Host: example.com
>>> Cache-Control: max-age=45, no-cache
>>> 
>>> Which I *hope* we can agree should be interpreted conservatively.
>> 
>> No, that's not what the client wants.  The client wants an HTTP/1.1
>> compliant cache to obey max-age=45, not no-cache, but fears the
>> presence of non-compliant caches that only understand Pragma.
>> Hence, both headers are sent.  If the client wanted no-cache
>> semantics, it would have sent no-cache in *both* fields.
>> 
>> Pragma has the same relation to CC as Expires.  If that isn't defined
>> in 2616, then it is surely an error in 2616.
> 
> OK. How do we specify this? Saying "When CC is present, you can ignore Pragma" brings about the case where:
> 
> GET /foo HTTP/1.1
> Host: example.com
> Cache-Control: myweirdextension=foo
> Pragma: no-cache
> 
> means that a HTTP/1.1 cache that doesn't implement myweirdextension now silently ignores the no-cache.

Which is why it says that extensions can override existing
declarations.  The client would never send the above.  It
would send "Cache-Control: no-cache, myweirdextension=foo" and
myweirdextension would be defined to override the semantics of
no-cache for those caches that support myweirdextension.

> We do already say
> 
>> A client SHOULD include both header fields when a no-cache request is sent to a server not known to be HTTP/1.1 compliant.
> 
> 
> ... but that's only a SHOULD (hey, the Subject *is* relevant!).
> 
> If we go in this direction, AFAICT we'd end up changing 
> 
>>   When the no-cache directive is present in a request message, a cache
>>   SHOULD forward the request toward the origin server even if it has a
>>   stored copy of what is being requested.  This pragma directive has
>>   the same semantics as the no-cache response directive (see Section 3.2.2
>>   ) and is defined here for backward compatibility with
>>   HTTP/1.0.  A client SHOULD include both header fields when a no-cache
>>   request is sent to a server not known to be HTTP/1.1 compliant.  A
>>   cache SHOULD treat "Pragma: no-cache" as if the client had sent
>>   "Cache-Control: no-cache".
> 
> 
> to something like
> 
> """
> When the no-cache pragma directive is present in a request, a cache MUST treat the request as if it contains the no-cache cache-control directive [ref], unless the Cache-Control header is also present in the request. 
> 
> A client SHOULD include both pragma and cache-control directives when sending a no-cache request , unless Cache-Control: no-cache is omitted to target other Cache-Control directives at HTTP/1.1 caches, while precluding HTTP/1.0 implementations from using a cached response.
> """
> 
> Is that workable?

Sounds like torture to me.  What is wrong with just ignoring Pragma
if Cache-Control is given and obeyed?

....Roy
Received on Thursday, 5 May 2011 02:32:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:40 GMT