W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2008

RE: i37: Vary and non-existant headers

From: Brian Smith <brian@briansmith.org>
Date: Tue, 29 Jul 2008 14:16:29 -0500
To: "'Mark Nottingham'" <mnot@mnot.net>
Cc: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-ID: <8CAFA7F61015444CA57D7E76A167530E@T60>

Mark Nottingham wrote:
> On 28/07/2008, at 6:35 PM, Brian Smith 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?

> >> * 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.
> 
> 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
Received on Tuesday, 29 July 2008 19:17:05 GMT

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