[Mod_gzip] Gzip encoding, IE 5 & 6, proxy caches, NetCache
Nigel Hamilton
mod_gzip@lists.over.net
Fri, 4 Oct 2002 17:59:54 -0500 (CDT)
HI Kieran,
Great research.
There may be a solution to the problem. When using Gzip + SSL I
know some people precede the document with 2048 space characters (these
compress easily) ... it's not elegant but it is reported to work.
Could this help with the bug you've found?
I wonder if they are the same bug?
Maybe the next version of GZIP could include a configuration
directive to "space pad" the response to fix the Exploder bug?
Good luck. Please let the list know if you find anything else out.
NIge
> 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
> >
>
> _______________________________________________
> mod_gzip mailing list
> mod_gzip@lists.over.net
> http://lists.over.net/mailman/listinfo/mod_gzip
>
--
Nigel Hamilton
Turbo10 Metasearch Engine
email: nigel@turbo10.com
tel: +44 (0) 207 987 5460
fax: +44 (0) 207 987 5468
________________________________________________________________________________
http://turbo10.com Search Deeper. Browse Faster.