Re: ETags vs Variants, was: Revising RFC2616 - what's happening

Julian Reschke wrote:
> Aha.
> 
> I would say that if the value for "Vary" changes between to HTTP 
> requests, the sever implementation/configuration has somehow changed, 
> and a proxy should invalidate all cached entries for that URI.

No, no.

The natural implementation is for the server to note each time a
request header is examined to compute the response, and to emit Vary
with those headers.

That set can be different depending on the path taken by the server
logic, _without_ changing the server implementation/configuration.

Consider, for example, a server implementation that does this (this
is reasonable):

   1. Look at "Accept-Encoding" to decide if known compression methods
      are supported as a content-encoding.

   2. If compression is supported, then for some types of response,
      look at "User-Agent" to check for certain agents that do not
      behave correctly for some compressed content types.

That server would produce the following two _correct_ responses, for
different request headers:

   a. Vary: Accept-Encoding

   b. Vary: Accept-Encoding, User-Agent
      Content-Encoding: gzip

If you specify that a cache must purge all variants when receiving a
Vary header which is different from previously received Vary, then
servers will realistically have to send "Vary: Accept-Encoding,
User-Agent" even in the case that the response _doesn't_ depend on
User-Agent.

In this particular example, it's easy to imagine writing the server to
do that; i.e. to always emit the same Vary for the compression test.
Although, it would clearly be sub-optimal.

However, when the server's use of request headers is less tightly
coupled, it's _much_ harder to do that.

For example, consider a server which renders pages from templates
(PHP, Perl, etc.), as many of them do.

And imagine that a template is selected depending on the language(s)
in Accept-Language.

And that some of those templates just emit some text in an appropriate
language, but some of them contain code which looks at
Accept-Charset to make further decisions.

The server could not possibly send "Vary: Accept-Language,
Accept-Charset" for _all_ the transmited variants, because for some of
them, it executes a template which doesn't look at Accept-Charset; the
server has no information that _other_ templates would do that.

A reasonable implementation is for the server to construct Vary
depending on the headers looked at by code in the templates.  And that
results in different variants having different Vary headers, quite
reasonably, with clearly defined semantics, and quite difficult to do
otherwise.

-- Jamie

Received on Sunday, 22 October 2006 03:35:47 UTC