Vary

There has been a lot of heated debate during the past few days
on the topic of the Vary header.  The "editorial group" did make
some changes that do not meet with the agreement of every single
member of the working group, and although I basically agree with
the bulk of the changes (not necessarily all of the details), I
think we've not done a great job at explaining the reasoning
behind them.  So, at the risk of wasting even more Internet
bandwidth, I'll try to do this without being pejorative.

We've done two major things (in addition to a lot of wordsmithing):

(1) Entirely decouple Vary and Alternates.
(2) Simplify the syntax of the Vary header

The main reason for change #1 is because we saw an obvious need
for the Vary mechanism, and we did not want to complicate it by
coupling it to an essentially undefined Alternates mechanism.
We felt that orthogonality made the HTTP/1.1 specification much
simpler.

The change we made, which basically requires the server to
send Vary whenever the response depends on anything besides
the Request-URI (and time), simply eliminates the optimization
that allows the server to omit Vary when Alternates is also
sent.  As Jim observes, the added overhead of sending "Vary:*"
is not enough to get upset about.

Now, Vary serves exactly one purpose: it prevents a cache from
returning the wrong response, when the selection of the right
response depends on something other than the Request-URI.  Period.
(It might be possible to use it for other things, such as
deciding what to delete from a cache, but that's not required
or prohibited by the specification.)

It's possible that this design decision may reduce the opportunities
for caching in future versions of HTTP.  Or, more likely, it
might reduce the opportunities for HTTP/1.1 caches to cache
responses from servers implementing a future version of HTTP.
But all of the studies I've seen show that HTTP caches do not
achieve such great hit rates, and so a small reduction in
potential future cache hits is a reasonable price to pay for
simplifying the HTTP/1.1 specification (and getting it adopted
and implemented sooner).  Earlier implementation of HTTP/1.1
will definitely improve the opportunities for caching (since
it avoids many of the problems that now lead to cache-busting).

As I said, I don't want to defend every jot and tittle of the
latest version of Vary, but I think it's important to avoid
the trap of arguing about possible future second-order performance
aspects of something that has a clear first-order short-term
performance effect.

-Jeff

Received on Tuesday, 28 May 1996 17:19:11 UTC