[Mod_gzip] Gzip encoding, IE 5 & 6, proxy caches, NetCache

Kieran Topping mod_gzip@lists.over.net
Fri, 4 Oct 2002 17:19:19 +0100


I've made some progress fixing this problem.
According to Microsoft there is a bug in IE5.5. In addition, I'm
experiencing the same problem with IE6.0. Anyway, they detail it at the
following location. Excerpts follow.
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q313712

I've also included, at the end of this email, a minimal criterion set for
reproducing this problem, which *must* be more widespread than it appears
from my browsing of mailing lists. Especially as it affects sites as large
as Google and Yahoo! and ALL server side gzip compression utilities
(including mod_gzip).

>>
...Microsoft Internet Explorer may lose the first 2048 bytes of data that
are sent back by a Web server when the Web server uses Hypertext Transfer
Protocol (HTTP) compression. This issue occurs when a program registers a
name space handler for any of the following protocols:
 * HTTP
 * HTTPS
 * File Transfer Protocol (FTP)
 * Gopher
 * File
For example, Real Download registers name space handlers for HTTP and FTP.
This loss of data causes script errors, poor display of Hypertext Markup
Language (HTML) elements, and so on.
<<

Their suggested solutions are as follows

>>
 * Disable HTTP compression (you can do this by using
   either HTTP 1.0 on the client or by changing the
   Web server's configuration).
   (# in my opinion not really acceptable, k)
 * Delete any of the registry keys that are in the
   following location:
   HKEY_CLASSES_ROOT\Protocols\Name-Space Handler
   Note that this prevents the program that registered
   that name space handlers from working as expected.

   (# slightly more acceptable, k)
 * Uninstall the program that registers name space
   handlers for one of the protocol listed above.

   (# ditto, k)
<<

Now, I've done some investigation, and it appears that - furthermore - as
far as IE6 is concerned, this problem only manifests itself when the browser
is using a proxy (either transparently, or explicitly). In particular, the
NetCache proxy (although possibly with others).

Also, the suggestion in the article that simply checking that you have a
version of urlmon.dll later than 5.50.4913.700 is erroneous. I'm running IE6
with version 6.x of urlmon.dll, and am still experiencing the problem.

So, based on my current evidence, a minimal set of criteria that will cause
gzip encoded responses to be corrupted are:

1. Run a windows-based machine
2. Run IE5 or IE6
3. Have RealDownload installed (or some other application
   that writes keys to the following location in the registry:
   HKEY_CLASSES_ROOT\Protocols\Name-Space Handler)
4. Use a proxy server, either:
     Implicitly (ie, your ISP has a transparent proxy)
     Explicitly (ie, you have set up a IE's options to use a proxy) (*)

The above criteria will lead to webpages being predictably currupted, on
account of their first 2048 (I haven't checked this number!) bytes being
stripped (NB Not on the initial download, but upon subsequent refreshes /
ctrl-refreshes)

I've tried submitting this to Microsoft but - thus far - to no avail.
Does anyone else have any more information pertaining to a possible solution
to this problem?
Or suggestions as to how to get Microsoft to take seriously the fact that it
needs to be fixed.
I'm starting to wonder whether they have an aversion to compressed content
being served over the web? Mozilla and Netscape work fine...

Many thanks, in advance,

Kieran

(*) Here is a (currently) open Netcache proxy that can be used:
proxy.ord.marketscore.com 80



----- Original Message -----
From: "Kieran Topping" <kieran@kitsite.com>
To: <mod_gzip@lists.over.net>
Sent: Tuesday, August 13, 2002 10:57 AM
Subject: [Mod_gzip] Gzip encoding, IE 5 & 6, proxy caches, NetCache


> I am getting some very strange results when trying to gzip-encode content.
>
> I'm not specifically using mod_gzip; however the problems I'm experiencing
> appear to be concerned more with browser versions and with proxy servers
> than they are to do with the webserver compression code.
>
> The problems I'm experiencing have already been documented in previous
> posts: mainly pages in IE (5 & 6) either not loading, partially loading,
or
> loading with garbled content (truncated at the beginning or end).
>
> There is a lot more evidence I have amassed about the specific
circumstances
> in which this occurs, which I can provide either on or off-list, if
> requested. However, one *big* factor, that occurs time and time again, is
> that IE (5 & 6) appear to specifically dislike dealing with gzip-encoded,
> chunked content served via the (very common) "NetCache" web-proxy
> (http://www.netapp.com/products/netcache/). All experiments I have
conducted
> *have* worked with Netscape 6.2, and Mozilla, which would tend to suggest
to
> me that this is an Internet Explorer bug.
>
> Generally, the first time a page is downloaded, it works fine, but
> subsequent downloads appear to exhibit the problems.
>
> Simple example
> ==============
>
> One simple test, repeatable time and time again on my PC (running Win
2000,
> using IE 5 & 6), and others, is to:
>
> * Ensure that IE's HTTP content is downloaded via a "NetCache" proxy cache
>   How?
>   Either:
>      Transparently, for instance by connecting to a Freeserve dial-up
> account
>      (Freeserve, and many other ISPs, use NetCache as a proxy cache)
>   or
>      Explicitly, by manually setting IE to use a NetCache proxy cache
>      (Tools->Internet Options->Connection->LAN Settings)
>      An open cache you can use is www-cache.demon.co.uk (port 8080)
>      If you do it this way, you must also configure IE to use
>      HTTP/1.1 via proxies (in Tools->Options->Advanced)
>
> * Go to Google (http://www.google.com) in IE
>   Google uses gzip compression. Generally, the first download works fine.
>
> * Hit "Refresh".
>   For me, this refresh renders the same page but with the first couple of
> thousand bytes missing.
>
> Subsequent refreshes yield the same result, despite the fact that - as
found
> out by sniffing the network - exactly the same response is being served
each
> time!
>
> I would be intrigued to know whether anyone else has experienced similar
> problems as this has been driving me to near distraction.
>
> NB The above example isn't valid for IE for the Mac, as it doesn't support
> gzip-encoded content.
> Furthermore, if relevent, the versions of IE that I've been using are
5.5.40
> and 6.026.
>
> I would be delighted to enter into a dialogue either on or off-list with
> anyone who has experienced similar frustration, might want some further
> information, or might have any solutions!
>
> Kind regards,
> Kieran
> kieran@kitsite.com
>
> _______________________________________________
> mod_gzip mailing list
> mod_gzip@lists.over.net
> http://lists.over.net/mailman/listinfo/mod_gzip
>