Re: i37 - Vary and non-existant headers

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