Subject: i37: Vary and non-existant headers

From: Mark Nottingham <[email-masked]>
Date: Mon, 28 Jul 2008 16:18:45 +0100

http://tools.ietf.org/wg/httpbis/trac/ticket/37

Roy sort-of proposed deleting "present" in <http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0090.html 

In addition, I'd propose:

* adding: "When a resource's representations vary, an origin server  
SHOULD include the Vary header even when the selecting header(s) are  
not present; otherwise, caches will use that representation  
inappropriately."

* adding: "Caches MAY canonicalise request headers before comparing  
them for purposes of determining whether they match during variant  
selection."

--
Mark Nottingham     http://www.mnot.net/

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 28 Jul 2008 12:35:12 -0500

Mark Nottingham wrote:
> Roy sort-of proposed deleting "present" in 
> <http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/0090.html
>  >
> 
> * adding: "When a resource's representations vary, an origin 
> server SHOULD include the Vary header even when the selecting 
> header(s) are not present; otherwise, caches will use that 
> representation inappropriately."

I think it would be better to say: "For each request URI, an origin server
SHOULD return the same Vary header field value for every request." In this
way, the Vary header is not just a response header but a "resource header".

> * adding: "Caches MAY canonicalise request headers before 
> comparing them for purposes of determining whether they match 
> during variant selection."

Clients, intermediaries, and servers should always be able to canonicalize
headers in any situation. Putting a specific statement about it here imples
there are some cases in which canonicalization is not allowed. I suggest
leaving this part out.

- Brian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 29 Jul 2008 08:13:03 +0100

> way, the Vary header is not just a response header but a "resource  

That is exactly how Vary doesn't work, and the interpretation that  
we're trying to avoid.

> there are some cases in which canonicalization is not allowed. I  

Enough people have had questions about this that it's worthwhile  
calling out explicitly, AFAICT.

Others?

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 29 Jul 2008 01:00:46 -0700

Vary is just an instruction to caches.  It would be the same category as
cache-control, except that Vary is response-only.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 29 Jul 2008 16:42:40 +0100

Julian just pointed out that 2616 6.2 does indeed list Vary as a  
response header; so, we just need to update p6 16.4.

--
Mark Nottingham       [email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Tue, 29 Jul 2008 20:28:46 +0200

Mark Nottingham wrote:
> That is exactly how Vary doesn't work, and the interpretation that we're 
> trying to avoid.

Right.

> Enough people have had questions about this that it's worthwhile calling 
> out explicitly, AFAICT.
> 
> Others?

I'd put it in; but maybe the topic could be mentioned in a more generic 
context again.

BR, Julian

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 29 Jul 2008 14:16:29 -0500

Mark Nottingham wrote:
> > I think it would be better to say: "For each request URI, an origin 
> > server SHOULD return the same Vary header field value for every 
> > request."
> > In this way, the Vary header is not just a response header but
> > a "resource header".
> 
> That is exactly how Vary doesn't work, and the interpretation 
> that we're trying to avoid.

I did make a mistake when I wrote that because I didn't include anything
about the request method. But, isn't it true that (request-URI,
request-method) -> Vary must be a function in order for caches to work?
Whenever I get a different Vary header for the same (request-URI,
request-method) combination I automatically mark the cached entities for
that pair as needing revalidation, since I assume that a changing Vary
header indicates some kind of server reconfiguration. Am I being too
conservative here?

> >> comparing them for purposes of determining whether they
> >> match during variant selection."
> >
> > Clients, intermediaries, and servers should always be able to 
> > canonicalize headers in any situation. Putting a specific statement 
> > about it here imples there are some cases in which 
> canonicalization is 
> > not allowed. I suggest leaving this part out.
> 
> Enough people have had questions about this that it's 
> worthwhile calling out explicitly, AFAICT.

First, what is the definition of "canonicalise"? I assumed that you just
meant normalizing whitespace and combining multiple fields with the same
name into a single field of comma-separated values. As far as I can tell, no
other canonicalization is allowed, since "a proxy MUST NOT change the order
of these field values" [4.2] and "a transparent proxy SHOULD NOT modify an
end-to-end header unless the definition of that header requires or
specifically allows that" [13.5.2]. 

We shouldn't mislead readers to think that they can convert
"Accept-Encoding: gzip, deflate" to "Accept-Encoding: deflate, gzip" or
"Accept: text/plain;q=1.0" to "Accept: text/plain;" since those kinds of
transformations have already been explicitly forbidden.

Regards,
Brian

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 31 Jul 2008 04:56:47 +0200

> request-method) -> Vary must be a function in order for caches to work?

No.

If there is multiple matching entities then caches is free to send any
unexpired one, preferably the latest...

> header indicates some kind of server reconfiguration. Am I being too

I do the same, but it's not what the spec intends. We covered this in
great length some year ago.

> transformations have already been explicitly forbidden.

Indeed.

I see no need to mention normalization here, other than referencing P3
4.2.

Regards
Henrik