httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joshua Marantz <>
Subject Re: Vary:User-Agent, best practices, and making the web faster.
Date Sun, 05 Jun 2011 00:15:46 GMT
On Sat, Jun 4, 2011 at 7:58 PM, Ben Noordhuis <> wrote:

>  > And I still don't understand how that relates to Vary:User-Agent.
>  What's
> > really at issue here seems more related to proxies; is that right?  That
> > proxies were not respecting Accept-Encoding, but sending gzipped content
> to
> > browsers that did not want it?  Is that still a problem?  Which proxies
> were
> > broken?  Are they still broken?
> Some popular OSS packages depend on Vary: User-Agent to make
> downstream proxies (reverse or forward) do the right thing.

I'm pretty interested in deconstructing this further.  Can you be more
specific?   Which OSS packages?  Under what scenario would a proxy do the
wrong thing in the absence of Vary:User-Agent (other than, obviously, when
the content actually varies based on user-agent)?

> And, while I understand the reluctance to help me figure out from our
> module
> > what values were passed to SetEnvIfNoCase and Header, I would like to see
> > whether there's agreement that the Apache 2.2 docs for mod_deflate are no
> > longer appropriate -- and in fact harmful.
> I've been mulling it over for 10 minutes and I can't decide. It's
> harmful because it leads to a proliferation of cached objects (bad)

I think that at least some proxies would likely decide to simply *not* cache
in the presence of vary:user-agent, rather than explode their caches.  That
makes the web slower.  But, Varnish, in particular, will explode its cache:  I believe that
will also make the web slower, because the hit-rate will suffer and they'll
be less room the cache for differentiated content.

> but removing it from the documentation will break things for someone
> somewhere (also bad).

I'm trying to get a handle on exactly what would break, and for whom :)


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message