Subject: relative weights of different Accept-* headers in content negotiation

From: Adrien de Croy <[email-masked]>
Date: Wed, 27 May 2009 13:43:03 +1200

Hi all

The content negotiation headers all have q values in them to indicate 
preference.  This leads to dilemmas in certain situations.

E.g. A cache has 2 representations of a URI:

one contains
Content-Language: en-nz
Content-Encoding: gzip

other contains
Content-Language: en-us

both are fresh and allowed to be returned.  It then gets a request for 
the URI which includes

Accept-Language: en-us, en; q=0.8
Accept-Encoding: gzip, *;q=0.8

So, the client is indicating a preference for US english and gzipped.  
We've got one gzipped, and the other in US english. How do we determine 
which is the best one?

If we are to accumulate an aggregate score for each stored 
representation, we'll end up with the same score for both unless we 
weight the headers.

Is there any de-facto standard or BCP for preference of one Accept-* 
header over another?   Or is it up to the server / cache to pick a 
representation to serve from other means?

Thanks

Adrien

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 26 May 2009 20:54:34 -0500

> We've got one gzipped, and the other in US english. How do we determine

Part 6 Section 2.6:

   Caches MUST use the most recent response (as determined by the Date
   header) when more than one suitable response is stored.  They can
   also forward a request with "Cache-Control: max-age=0" or "Cache-
   Control: no-cache" to disambiguate which response to use.

> representation, we'll end up with the same score for both unless we

Caches treat the Accept headers exactly the same as any other request
header. Only origin servers (and non-transparent proxies) interpret the
Accept header contents. 

> representation to serve from other means?

Polite servers will put some effort into choosing the most acceptable
response based on the client's preferences. However, servers aren't required
to be polite; they may ignore any/all parts of any/all Accept headers.

Regards,
Brian

---

From: Adrien de Croy <[email-masked]>
Date: Wed, 27 May 2009 14:10:31 +1200

>    Control: no-cache" to disambiguate which response to use.
OK, thanks for that.  I guess that will lead to some unexpected 
behaviour in some cases (as far as a browser user is concerned), since a 
user could end up getting content in an unexpected (but not unwilling to 
accept, albeit at a very low q value) language purely because it is fresher.

Hence my comment on this in a previous mail.  By choosing Date as the 
ultimate disambiguator, we are effectively stating that Date is the most 
important dimension.  Lots of customers would disagree with that, but I 
guess this will affect very very few people.

> header. Only origin servers (and non-transparent proxies) interpret the
OK, my example should have referred to a non-transparent proxy actually 
since this is what I'm implementing the cache for at the moment. 

So it's a shared cache scenario.  It can't be legal to send gzipped 
content to a UA that didn't advertise support for it, so the proxy 
therefore must consider Accept-* headers.

> to be polite; they may ignore any/all parts of any/all Accept headers.
thanks

Adrien

---

From: "Brian Smith" <[email-masked]>
Date: Tue, 26 May 2009 21:26:06 -0500

Adrien de Croy wrote:
> behaviour in some cases (as far as a browser user is concerned), since
> a user could end up getting content in an unexpected (but not unwilling
> to accept, albeit at a very low q value) language purely because it is
> fresher.

That is why servers shouldn't return cacheable responses without a Vary
header.

> > header. Only origin servers (and non-transparent proxies) interpret
> > the Accept header contents.

> since this is what I'm implementing the cache for at the moment.

A non-transparent proxy can do almost whatever it wants. The rules for
caches do not apply to it.

> therefore must consider Accept-* headers.

Caches do not need to interpret Accept-* headers; that is why Accept-*
headers are not mentioned at all in Part 6 (except for obscure case of
determining the language to use for messages in Warning headers).

See the definitions of the Accept-* headers. For example, "If no
Accept-Encoding field is present in a request, the server MAY assume that
the client will accept any content coding." There are actually a lot of
rules for determining what the server SHOULD do. But, there are no MUST-
level requirements for how servers interpret Accept-* headers.

Regards,
Brian

---

From: Adrien de Croy <[email-masked]>
Date: Wed, 27 May 2009 15:44:22 +1200

> determining the language to use for messages in Warning headers).
OK.  That seems counter-intuitive, so it could be worth putting an 
explanatory note to that effect in Part 6 somewhere.

Thanks

Adrien