On Tue, 4 Jun 2002, Alvar Freude wrote: > >> Also compressed output does not work on IE, if the request was POSTed > >> (only tested with older version, I gess 4.0, of IE). > > > > I did not know about IE4 and POSTs, at least I did not received > > mod_deflate bug reports about it. > > I realized this on http://www.a-blast.org/ when posting some texts. As I > remember this was very strange, because sometimes it works but mostly not. > > > > I know two IE4 gzip bugs. They > > described in http://sysoev.ru/mod_deflate/readme.html#browsers (sorry, > > Russian only). > > hmm, Don't understand Russion ;) -- perhaps it's a siede effect of one of > this bugs?
I think these bugs unrelated. 1. MSIE 4.x can not handle gzipped response if its URL without "http://"; prefix is bigger then 253 bytes. 2. MSIE 4.x has bug with gzipped response and byte-range request (I found this bug while testing mod_deflate and it should never occured under usual conditions). > >> # Important: we change output > >> # according to this headers > >> $r->header_out('Vary', 'Accept-Encoding, User-Agent'); > > > > It's not good idea - it disables caching in MSIE. > > really? > hrmpf! > > I tested it now with MSIE 5.5; sometimes it fetched the file, sometimes it > came from cache. I also remember, that at another project i set for testing > purpose the expire time +1000000 seconds. And forgot it to remove after > testing. AARRGH! ==> MSIE cached the page even if there was a hard reload, > the old page remains in cache. It was a hard to find bug ;-) > > But "Vary" there was also set, so it seems that at least under some > circumstances MSIE caches data with vary. In my tests MSIE did not cache responses with any "Vary" header. > I included it because a proxy server may get an request from a browser > which understands gzip; and some seconds later from one who doesn't > understand it (i.e. MSIE Mac). So, if the proxy forwards the compressed > data to the second browser this will fail. > > What experiences do you have with this? By default mod_deflate does not gzip responses to proxied requests (that have "Via" header) and HTTP/1.0 requests. It can be overridden. > >> # don't forget Content-Length! > >> # it enables keepalive and > >> # disables some Netscape bugs > >> $r->header_out('Content-Length', length(${ $out->{document} })); > > > > I'm not sure that sending Content-Length with gzipped content is good > > idea. MSIE understands chunked transfer and can keep alive connection. > > For NN4 we should close connection. > > i mostly closed connection , because keep alive blocked a bug Apache (on > http://www.a-blast.org/ each httpd is about 38-42 MB, but mostly shared); > but now i moved to frontend and backend apache, so there are not too much > memory consumption thrown away for static requests or requests to my other > Vhosts. > > I had several really *hard* problems without Content-Length and NN4: > > If in the page is some document.write JavaScript and there is no > Content-Length, NN4 writes some of the document.write-Code into a random > part of the HTML file. :-( This often destroys the hole page, e.g. if it > overwrites closing <table>-Tags. > Several weeks i searched for this ugly bug, because sometimes it destoys > the page and sometimes not. If destoying, Netscape does also not realise > that the connection is already closed and the stars are moving, indicating > further loading. But when the content-length is correctly set, it works. > > I guess that NN4 gets confused with the end of the page and when he should > start with running of the JavaScript. I usually disable javascript in my NN4 (it's so buggy) so I did not see this problem. Igor Sysoev http://sysoev.ru
