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

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

From: Adrien de Croy <adrien@qbik.com>
Date: Thu, 05 May 2011 15:57:14 +1200
Message-ID: <4DC2201A.3040507@qbik.com>
To: Mark Nottingham <mnot@mnot.net>
CC: "Roy T. Fielding" <fielding@gbiv.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, HTTP Working Group <ietf-http-wg@w3.org>

having the override be conditional on whether the CC header contained 
understood directives or not seems like not a great idea to me.

I'd have presumed that if the CC header exists, Pragma should be ignored 
- regardless of what directives are contained or whether they are 
understood or enacted.

The reasoning being:

* Pragma was an HTTP/1.0 header
* anyone implementing this RFC is implementing HTTP/1.1
* Pragma was recommended in RFC2616 to cope with HTTP/1.0 caches

therefore an HTTP/1.1 client is only sending Pragma to target HTTP/1.0 
intermediaries, which implementations of this spec are not. The only 
other case where an intermediary would expect to see a Pragma is from an 
HTTP/1.0 client, in which case it wouldn't expect to see C-C.  HTTP/1.1 
clients are still perfectly free to send whatever C-C directives they 
choose.  It's actually more deterministic to ignore Pragma than treat it 
as a repeat C-C header (and therefore combine the headers).  Especially 
since precedence of cache directives isn't explicitly defined (another 
issue).

Regards

Adrien




On 5/05/2011 3:04 p.m., Mark Nottingham wrote:
> On 05/05/2011, at 12:32 PM, Roy T. Fielding wrote:
>
>>> """
>>> 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?
>
> "Obeyed" really needs to be qualified to those directives that are understood. I've have a go below; if you have suggestions, please provide specific text.
>
> """
> 3.4.  Pragma
>
> The "Pragma" header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header is also present and understood in a message, Pragma is ignored.
>
> In HTTP/1.0, Pragma was defined as an extensible field for implementation-specified directives for recipients. This specification deprecates such extensions to improve interoperability.
>
>       Pragma           = 1#pragma-directive
>       pragma-directive = "no-cache" / extension-pragma
>       extension-pragma = token [ "=" ( token / quoted-string ) ]
>
> 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 and the cache obeys those cache-control directives [ref] that it contains (excepting any extensions that are not understood [ref]).
>
> A client SHOULD include both pragma and cache-control directives when sending a no-cache request, unless Cache-Control: no-cache is purposefully omitted to target other Cache-Control response directives at HTTP/1.1 caches. For example:
>
> GET / HTTP/1.1
> Host: www.example.com
> Cache-Control: max-age=30
> Pragma: no-cache
>
> will constrain HTTP/1.1 caches to serve a response no older than 30 seconds, while precluding implementations that do not understand Cache-Control from serving a cached response.
> """
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Thursday, 5 May 2011 03:57:50 GMT

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