"Paul J. Keenan" wrote: > > 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. > Yes, I believe you are right, and I was wrong about the server sending the content down uncompressed, since simple ftp clients receive it compressed. Interestingly lwp-request shows "gzip" as the content-encoding when it gets
ftp://ftp.debian.org/debian/dists/potato/main/source/text/less_346-7.diff.gz ^^^ So their *ftp* server sends a different content-encoding string, but one that Netscape still seems to internally decode. But simpler ftp clients don't seem to, so that's the answer for now. I really don't understand about all this header stuff in relation to an ftp server; I wish someone would enlighten me...
