RE: i37: Vary and non-existant headers

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 UTC