Re: Netscape 4.5 and HTTP/1.1 Accept-Encoding

On Tue, 3 Nov 1998, Dave Kristol wrote:

> David W. Morris wrote:
> > 
> > On Tue, 3 Nov 1998, John Franks wrote:
> > 
> > > On Tue, 3 Nov 1998, Dave Kristol wrote:
> > >
> > > I  think gzip and compress are different encodings.  The fact that
> > > a program called "gzip" understands both is not relevant.
> 
> [N.B.  I never received John Franks's message, either directly, or via
> the mailing list.]
> 

> Yup, folks, I really did know they are different encodings.  My point
> was that perhaps NS 4.5 was able to decode both "gzip" and "compress"
> encodings because the gzip *program* can decode both.  Just a hunch,
> although I was told privately that NS 4.5 probably cannot decode
> "compress".
> 

I just tested and Netscape 4.5 for Unix seems to handle gzip and
compress just fine.  Here a file xxx.ps.Z was requested (presumably
with Accept-Encoding only containing gzip) and a compressed 
ps document was returned with Content-Encoding x-compress and 
Content-type application/postscript.  NS properly uncompressed it
and handed it off to the postscript viewer.

> I think Koen's remarks were most appropriate about not sending 406 in
> the absence of negotiation.  However, I don't agree with the idea of
> sending Content-type: application/x-compress, except in a nice
> theoretical world.  Browsers that don't send Accept-Encoding work quite
> nicely with my server (assuming they understand x-compress).  So I'm
> more inclined just to ignore Accept-Encoding.

I think I agree with this.  It is current practice in HTTP/1.0 so it
should continue there, at least.  But I think Dave may be right and 
this is good behavior in 1.1.  Any disagreement?

Given that this behavior does not fail ungracefully in current 1.0
browsers, I would assume that 1.1 browsers would also do something
reasonable (save to disk) when they can't handle a given content encoding.

> 
> To John Franks's (apparent) question, what do I send in the absence of
> Accept-Encoding:  I send Content-Type: application/postscript and
> Content-Encoding: x-compress.  I would not send
> application/octet-stream.
> 

Well, on reflection, I think you are right.  And that's what my server
does too.  :)


> I disagree mildly with Dave Morris's unhappiness that browsers, etc.,
> might uncompress something for him.  What *I* want varies with the
> situation.  If I have a viewer for PostScript or PDF, for example, I
> want the incoming compressed object to be uncompressed and passed to the
> viewer.  OTOH, if I'm saving a file, I *don't* want the object to be
> uncompressed.  (Maybe that's what he meant.)
> 

Again I agree with this behavior, but I am not sure the protocol has
something to say about it.

John Franks
john@math.nwu.edu

Received on Tuesday, 3 November 1998 15:20:09 UTC