Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: modules-dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of info@bnoordhuis.nl designates
 74.125.83.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <BANLkTimvQhe1Dyrafz+-vGege0Qk5bOOPw@mail.gmail.com>
References: <BANLkTimyVhVod5fKeQzs_F562rBLS0sWFQ@mail.gmail.com>
	<BANLkTimSzONrUDB6zFrve-70Uk3L=sX=TA@mail.gmail.com>
	<BANLkTimvQhe1Dyrafz+-vGege0Qk5bOOPw@mail.gmail.com>
Date: Sun, 5 Jun 2011 01:58:40 +0200
Message-ID: <BANLkTinnMQt0W4becz56cFY2aj2P6AqmUA@mail.gmail.com>
Subject: Re: Vary:User-Agent, best practices, and making the web faster.
From: Ben Noordhuis <info@bnoordhuis.nl>
To: modules-dev@httpd.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sun, Jun 5, 2011 at 00:34, Joshua Marantz <jmarantz@google.com> wrote:
> It was with some reluctance that I brought this up. =A0It occurs to me th=
at
> this idea propagates the sort of spec violations that led to this issue
> (inappropriate user of Vary:User-Agent) in the first place. =A0 However, =
I'm
> trying to figure out how to improve compliance to support legitimate uses=
 of
> Vary:User-Agent without causing mod_pagespeed to become significantly les=
s
> ineffective across a broad range of sites.
>
> We have found that putting complaints in Apache logs mostly causes disks =
to
> fill and servers to crash -- although that does get it noticed :). =A0The
> problem, put another way, is that mod_pagespeed cannot distinguish
> legitimate uses of Vary:User-Agent, so it really has no business complain=
ing
> in logs. =A0Complaining in docs is fine; but some existing mod_pagespeed =
users
> that simply type "sudo yum update" will later notice a performance-drop a=
nd
> may not consult the docs to figure out why.
>
> I'm also trying to grok the first response from Eric:
>
> It's because of the other (dated) canned exceptions that set/unset
> no-gzip/gzip-only-text/html based on the User-Agent, to second-guess
> browsers that send AE:gzip but can't properly deal with it.
>
>
> Going backwards: =A0which browsers send AE:gzip but can't properly deal w=
ith
> it? =A0 Does IE6 have that issue or is it only true of IE5? =A0 I know th=
at IE6
> has had issues with compression in the past but they appear to be address=
ed
> by patches issued by Microsoft four and a half years ago:
> http://support.microsoft.com/default.aspx?scid=3Dkb;en-us;Q312496. =A0Mor=
eover
> IE6 is shrinking in market
> share<http://arstechnica.com/web/news/2011/05/web-browser-market-share-up=
grade-analysis.ars>(~
> 10%) and IE5 does not appear in the pie-chart at all.

This was indeed a (since fixed) problem with IE6. I haven't seen the
gzip issue crop up since but that is purely anecdotal.

> And I still don't understand how that relates to Vary:User-Agent. =A0What=
's
> really at issue here seems more related to proxies; is that right? =A0Tha=
t
> proxies were not respecting Accept-Encoding, but sending gzipped content =
to
> browsers that did not want it? =A0Is that still a problem? =A0Which proxi=
es were
> broken? =A0Are they still broken?

Some popular OSS packages depend on Vary: User-Agent to make
downstream proxies (reverse or forward) do the right thing.

> And, while I understand the reluctance to help me figure out from our mod=
ule
> 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)
but removing it from the documentation will break things for someone
somewhere (also bad).