Antwort: Re: [Mod_gzip] http 1.1 or 1.0 which to accept
mod_gzip@lists.over.net
mod_gzip@lists.over.net
Fri, 19 Mar 2004 13:00:52 +0100
Dies ist eine mehrteilige Nachricht im MIME-Format.
--=_alternative 004203DDC1256E5C_=
Content-Type: text/plain; charset="US-ASCII"
Hi Glenn,
> There is a long-outstanding bug in the current stable release of
> mod_gzip (fixed in CVS? I don't know) that errs a little too loosely
> when deciding to send Vary: User-Agent or Vary: * IIRC.
>
> If the pages returned have Vary headers, you might even be using
> MORE bandwidth than you did without mod_gzip compressed pages, since
> many proxies won't cache those pages or are restricted in what they
> can cache, and many browsers will re-request those pages more often.
first of all I don't think you should name a bug in the M$IE caching
algorithm
to be the fault of mod_gzip.
Yes, mod_gzip could be more intelligent about creating "Vary:" headers
but Christian decided to do what had to be done for Squid 2.5's purpose
and to "play it safe" without totally rewriting the rule evaluation code
of
mod_gzip, which would have been necessary as to find out the 'minimal'
"Vary:" header.
Then, increasing bandwidth again is not the effect of a "bug" in mod_gzip
but an effect of using a mod_gzip configuration for an environment where
this configuration is not appropriate.
If most of your users use a buggy browser (M$IE) that misinterprets "Vary:
*"
as 'don't cache locally' then you should be careful which MIME types to
use
mod_gzip for.
You can easily disable mod_gzip (and its "Vary:" generation code) for
<FilesMatch> sections in the Apache configuration, and that's what you
have to do in this case (exclude all MIME types where gzipping doesn't
produce compression factors better than 3, I'd guess).
Besides, not even invoking mod_gzip for MIME types that you know will
not compress effectively even saves CPU load on your machine...
This is just like you have to not compress JavaScript files if your
visitors are
still using Netscape 4 browsers - you wouldn't name that a "mod_gzip bug"
either, or will you?
> What are the risks in allowing http 1.0 - I see google allows it ?
I am not aware of any risks in allowing HTTP/1.0, and Netscape 4 (which
does not support HTTP/1.1) would be out of the game if you didn't even
try.
M$IE running in HTTP/1.0 mode doesn't even send "Accept-Encoding: gzip"
and will never request gzipped data from mod_gzip, so it is no problem.
The only problem that might arise would have been feeding a M$IE running
in HTTP/1.0 mode data that it didn't ask for, which could have happened
when using a caching proxy which doesn't know these data were the result
of a Content Negotiation over "Accept-Encoding" - exactly that's what the
"Vary:" header is fixing because it tells then Caching Proxy what to do.
Regards, Michael
P.S. I especially like your "Expires" configuration. Not many users of
compression
software seem to be aware that not having to send anything at all will
beat even
the best compression algorithm.
--=_alternative 004203DDC1256E5C_=
Content-Type: text/html; charset="US-ASCII"
<br><font size=2 color=red face="sans-serif"><b>Hi Glenn,</b></font>
<br>
<br><font size=2 color=red face="sans-serif"><b>> </b></font><font size=2><tt>There
is a long-outstanding bug in the current stable release of</tt></font>
<br><font size=2 color=red face="sans-serif"><b>> </b></font><font size=2><tt>mod_gzip
(fixed in CVS? I don't know) that errs a little too loosely</tt></font>
<br><font size=2 color=red face="sans-serif"><b>> </b></font><font size=2><tt>when
deciding to send Vary: User-Agent or Vary: * IIRC.</tt></font>
<br><font size=2 color=red face="sans-serif"><b>></b></font>
<br><font size=2 color=red face="sans-serif"><b>> </b></font><font size=2><tt>If
the pages returned have Vary headers, you might even be using</tt></font>
<br><font size=2 color=red face="sans-serif"><b>> </b></font><font size=2><tt>MORE
bandwidth than you did without mod_gzip compressed pages, since</tt></font>
<br><font size=2 color=red face="sans-serif"><b>> </b></font><font size=2><tt>many
proxies won't cache those pages or are restricted in what they</tt></font>
<br><font size=2 color=red face="sans-serif"><b>> </b></font><font size=2><tt>can
cache, and many browsers will re-request those pages more often.</tt></font>
<br>
<br><font size=2 color=red face="sans-serif"><b>first of all I don't think
you should name a bug in the M$IE caching algorithm</b></font>
<br><font size=2 color=red face="sans-serif"><b>to be the fault of mod_gzip.</b></font>
<br><font size=2 color=red face="sans-serif"><b>Yes, mod_gzip could be
more intelligent about creating "Vary:" headers</b></font>
<br><font size=2 color=red face="sans-serif"><b>but Christian decided to
do what had to be done for Squid 2.5's purpose</b></font>
<br><font size=2 color=red face="sans-serif"><b>and to "play it safe"
without totally rewriting the rule evaluation code of</b></font>
<br><font size=2 color=red face="sans-serif"><b>mod_gzip, which would have
been necessary as to find out the 'minimal'</b></font>
<br><font size=2 color=red face="sans-serif"><b>"Vary:" header.</b></font>
<br>
<br><font size=2 color=red face="sans-serif"><b>Then, increasing bandwidth
again is not the effect of a "bug" in mod_gzip</b></font>
<br><font size=2 color=red face="sans-serif"><b>but an effect of using
a mod_gzip configuration for an environment where</b></font>
<br><font size=2 color=red face="sans-serif"><b>this configuration is not
appropriate.</b></font>
<br><font size=2 color=red face="sans-serif"><b>If most of your users use
a buggy browser (M$IE) that misinterprets "Vary: *"</b></font>
<br><font size=2 color=red face="sans-serif"><b>as 'don't cache locally'
then you should be careful which MIME types to use</b></font>
<br><font size=2 color=red face="sans-serif"><b>mod_gzip for.</b></font>
<br><font size=2 color=red face="sans-serif"><b>You can easily disable
mod_gzip (and its "Vary:" generation code) for</b></font>
<br><font size=2 color=red face="sans-serif"><b><FilesMatch> sections
in the Apache configuration, and that's what you</b></font>
<br><font size=2 color=red face="sans-serif"><b>have to do in this case
(exclude all MIME types where gzipping doesn't</b></font>
<br><font size=2 color=red face="sans-serif"><b>produce compression factors
better than 3, I'd guess).</b></font>
<br><font size=2 color=red face="sans-serif"><b>Besides, not even invoking
mod_gzip for MIME types that you know will</b></font>
<br><font size=2 color=red face="sans-serif"><b>not compress effectively
even saves CPU load on your machine...</b></font>
<br><font size=2 color=red face="sans-serif"><b>This is just like you have
to not compress JavaScript files if your visitors are</b></font>
<br><font size=2 color=red face="sans-serif"><b>still using Netscape 4
browsers - you wouldn't name that a "mod_gzip bug"</b></font>
<br><font size=2 color=red face="sans-serif"><b>either, or will you?</b></font>
<br>
<br><font size=2><tt>> What are the risks in allowing http 1.0 - I see
google allows it ?</tt></font>
<br>
<br><font size=2 color=red face="sans-serif"><b>I am not aware of any risks
in allowing HTTP/1.0, and Netscape 4 (which</b></font>
<br><font size=2 color=red face="sans-serif"><b>does not support HTTP/1.1)
would be out of the game if you didn't even try.</b></font>
<br>
<br><font size=2 color=red face="sans-serif"><b>M$IE running in HTTP/1.0
mode doesn't even send "Accept-Encoding: gzip"</b></font>
<br><font size=2 color=red face="sans-serif"><b>and will never request
gzipped data from mod_gzip, so it is no problem.</b></font>
<br>
<br><font size=2 color=red face="sans-serif"><b>The only problem that might
arise would have been feeding a M$IE running</b></font>
<br><font size=2 color=red face="sans-serif"><b>in HTTP/1.0 mode data that
it didn't ask for, which could have happened</b></font>
<br><font size=2 color=red face="sans-serif"><b>when using a caching proxy
which doesn't know these data were the result</b></font>
<br><font size=2 color=red face="sans-serif"><b>of a Content Negotiation
over "Accept-Encoding" - exactly that's what the</b></font>
<br><font size=2 color=red face="sans-serif"><b>"Vary:" header
is fixing because it tells then Caching Proxy what to do.</b></font>
<br>
<br><font size=2 color=red face="sans-serif"><b>Regards, Michael</b></font>
<br>
<br><font size=2 face="sans-serif">P.S. I especially like your "Expires"
configuration. Not many users of compression</font>
<br><font size=2 face="sans-serif">software seem to be aware that not having
to send anything at all will beat even</font>
<br><font size=2 face="sans-serif">the best compression algorithm.</font>
--=_alternative 004203DDC1256E5C_=--