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

Re: .gz in Netscape

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


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


Reply to: