Hi Slava,
> For example, let's say that MSIE is requesting some.js
> file using HTTP/1.1 via Squid.
> It sends usual Accept-Encoding: gzip, and it really can
> uncompress gzip over HTTP/1.1.
> But Squid downgrades HTTP/1.1 to HTTP/1.0, and httpd sees
> HTTP/1.0 from MSIE accomplished with Accept-Encoding: gzip.
> We know exactly that MSIE does NOT speak gzip over HTTP/1.0.
> Will it be correct to respond gzip in this case?
> I have no clue.
I have. I am running a Netscape proxy that downgrades
each and every HTTP request to HTTP/1.0. My proxy does
not cache, but the requests that arrive at my Apache
are HTTP/1.0 and nothing else (I have my log files).
mod_gzip is working in this scenario. I have more than
90% requests that send "Accept-Encoding: gzip".
All that counts about M$IE is whether it _tried_ to
speak HTTP/1.1 - not whether it really _did_ speak
HTTP/1.1. I don't understand why Micro$oft implemented
it this way, but this is how it works.
> It's not clear, but just in case, let's imagine that I send
> back gzipped response over HTTP/1.0, and MSIE is lucky to
> uncompress it correctly.
Which is exactly what will happen.
> I'm accomplishing the response with Vary: Content-Encoding,
> and Squid caches it successfully.
Which will not happen for all Squids until 2.4, if I
understand the current behaviour correctly.
> The next NN-4.X is coming to Squid to order the same file
> over HTTP/1.0 with it's buggy Accept-Encoding: gzip.
> But Squid does not care about that. What the content
> will be delivered to that poor fellow on NN-4.X?
Yes, _this_ is a problem.
Squid doesn't know that Netscape is a liar (that cannot
handle compressed JavaScript files), and has to trust
the "Accept-Encoding" header it will send.
Netscape 4 will thus get the compressed content and will
fail to handle it correctly.
mod_gzip itself provides a configuration directive to
exclude Netscape 4 (or whatever you like) based on some
regular expression for some HTTP header.
I am not quite sure whether I should suggest Squid to do
the same, because in mod_gzip you have several options:
a) you may exclude Netscape 4 OR
b) you may exclude JavaScript files.
Whichever suits you best. (I do exclude JavaScript and CSS,
and I even embed both into HTML pages via SSI, because
_this_ will work even with Netscape 4.)
If you are the Apache server, you _know_ what a JavaScipt
file is, because you did define the MIME type mapping and
everything. So you can write "mod_gzip_item_exclude" rules
to prevent compression for files, URIs, MIME types, ...
Given a scenario where no proxies exist, this flexibility
is the great strength of mod_gzip. Given a scenario where
mod_gzip needs to tell what it did to other HTTP partners,
this may well be a problem as we see right now.
Greetings, Michael
Received on Tue Aug 27 2002 - 21:17:19 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:16:15 MST