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

RE: i37: Vary and non-existant headers

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Thu, 31 Jul 2008 04:56:47 +0200
To: Brian Smith <brian@briansmith.org>
Cc: "'Mark Nottingham'" <mnot@mnot.net>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-Id: <1217473007.28440.77.camel@henriknordstrom.net>

On tis, 2008-07-29 at 14:16 -0500, Brian Smith wrote:

> 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?

No.

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

> 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?

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

> 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.

Indeed.

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

Regards
Henrik
Received on Thursday, 31 July 2008 02:57:27 GMT

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