W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2007

Re: i37 - Vary and non-existant headers

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Fri, 16 Nov 2007 00:10:00 +0100
To: Adrien de Croy <adrien@qbik.com>
Cc: Jamie Lokier <jamie@shareable.org>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-Id: <1195168200.30372.158.camel@henriknordstrom.net>
On fre, 2007-11-16 at 09:46 +1300, Adrien de Croy wrote:

> If we don't take into account any meaning of headers, we lose many 
> opportunities to cache.

Maybe, unless the server supports ETag.

> E.g. if an original request for something contained an Accept-Language 
> header specifying many acceptable languages, the response comes back 
> with one of those languages.  If a subsequent request comes in which 
> will accept the language that is cached, should that be served back or not?

See 13.2 Caching Negotiated Documents for a detailed description of what
should happen in the point of the RFC.

> I guess there are difficulties there where for one request it was the 
> preferred language and for another it was a less-preferred language.

Yes, and is why the procedure in 13.2 exists, whereby the cache uses
If-None-Match to ask the origin which variant should be used for a new
kind of request.

> In which case how would you compare Accept-Language tags?  You'd need to 
> compare them as a list with q values.  Or would you do it so that if the 
> q value was 1 in the original request and subsequent request then its ok 
> to return that one?:

As a list-header, which is the compare function used for all headers in
this context (vary). Nothing special just because it's the
Accept-Language header. Same compare function used for Accept-Content or
X-FooBar.

The only one actually parsing Accept-Language (or the other Accept
headers) is the origin server when performing it's server driven content
negotiation dance selecting which variant to return for this request.

Regards
Henrik



Received on Thursday, 15 November 2007 23:10:19 GMT

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