Hi, -- Igor Sysoev <[EMAIL PROTECTED]> wrote:
> NN4 for Windows does not decompress gzipped Flash. NN4 for Unix does. aah, OK, I only checked it on Windows and then stopped compüressing everything else then text/html with NN4. > But no one browser decompress gzipped response that is fetched via > Flash's loadVariables() and XML.load() functions. yes, for this reason I disabled compression for all NN4 when the content-type isn't text/html. >> 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? > All NN4.5+ say "Accept-Encoding: gzip". NN4.0x for Unix and PPC Mac do > not say but understand it but they too rare now so you can ignore them. ah, OK. I'd stolen this part of the code from the GzipChain module. > NN4 also does not undresatnd gzipped application/x-javascript and ext/css: > http://sysoev.ru/mod_deflate/readme.html#types yes; therefor it's sure to only compress text/html on NN4 -- if not explicitly tested that it works. >> # 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. 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? >> # 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. Ciao Alvar -- // Unterschreiben! http://www.odem.org/informationsfreiheit/ // Internet am Telefon: http://www.teletrust.info/ // Das freieste Medium? http://www.odem.org/insert_coin/ // Blaster: http://www.assoziations-blaster.de/
