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

Adrien de Croy wrote:
> 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.

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

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

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

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

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

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