W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

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

From: Brian Smith <brian@briansmith.org>
Date: Tue, 26 May 2009 21:26:06 -0500
To: "'Adrien de Croy'" <adrien@qbik.com>, "'Brian Smith'" <brian@briansmith.org>
Cc: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-ID: <000a01c9de72$7e6cd730$7b468590$@org>
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
Received on Wednesday, 27 May 2009 02:26:40 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:19 UTC