[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: .gz in Netscape

"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 debian-user-request@lists.debian.org < /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:
> 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 


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...

Reply to: