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, BrianReceived 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