On Fri, Feb 04, 2000 at 12:15:45PM -0600, Keith G. Murphy wrote: > I am wondering if it is not the *server* behavior to send it > uncompressed. This happens to me too, but when I try one of the .tar.gz > files, it downloads compressed. Seems unlikely that my Netscape is > taking it upon itself to treat these differently. Notice that the > displayed icons are different for these also. > > I know I've got Apache set up to automatically decompress .gz files so I > can browse HOWTO's, etc. I wonder if the folks at ftp.debian.org got > smart with their server here also? Probably just sending a different > header to Netscape. Damn geeks! ;-) > > Only immediate solution I know of is to use a "dumb" FTP client like > lftp to download these. > > > -- > Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
I get the same error. I too was thinking about adding a mime-type to try to cure it. I tried : -------------------------------------------------------------------- funkiest:~$ lwp-request -de "http://ftp.debian.org/dists/frozen/contrib/binary-i386/Packages.gz"; Connection: close Date: Fri, 04 Feb 2000 19:41:34 GMT Accept-Ranges: bytes Server: Apache/1.3.6 (Unix) Debian/GNU Content-Encoding: x-gzip Content-Length: 33393 Content-Type: text/plain ETag: "1c0066-8271-389a0f57" Last-Modified: Thu, 03 Feb 2000 23:29:27 GMT Client-Date: Fri, 04 Feb 2000 19:41:41 GMT Client-Peer: 207.69.194.216:80 funkiest:~$ -------------------------------------------------------------------- So it looks like the document is billed by the server as being of mime- type text/plain, and it's the content enconding of x-gzip which tells Netscape that it needs to be decoded from gzipped format before the mime-handler can use the file. So it's perhaps more understandable why Netscape behaves as it does. I tried adding a mime-type to match the gz suffix, but this does not work. I guess that Netscape will prefer the server's definition of the mime-type over its own lookup table based on the suffix, so the added entry is never used. I tried renaming the gzip binary to see if it used the gzip program, figuring that some wrapper could be put around the netscape program with a modified environment which would call cat as the application, masquerading as gzip. Unfortunately there was still no success. So it looks like Netscape has it's own routine or uses calls in one of the shared libs it links to. I haven't completely given up yet, but I don't have any current ideas on how to work around this. One of those situations where having the source available would be of some small benefit ... :-) -- Regards, Paul
