Re: Netscape 4.5 and HTTP/1.1 Accept-Encoding

Dave Kristol:
>Something interesting has come up that's one of: a bug or infelicity in
>my server, or a bug or infelicity in Netscape 4.5
>Netscape 4.5 sends an HTTP/1.0 request with Accept-Encoding: gzip
>header.  A web site has a file, i.e., Content-type:
>application/postscript, Content-Encoding: compress.  When NS 4.5 tries
>to GET the paper, my server returns 406 Not Acceptable, because
>"compress" is not one of the accepted encodings.
>There seem to be two (not mutually exclusive) conclusions to draw:
>1) Netscape 4.5 should send Accept-Encoding: gzip, compress, because
>gzip (well, the gzip program, anyway) understands the Unix compress

Netscape would be allowed to include 'compress' in its Accept-Encoding
line, but there is nothing in the spec which says that it should.

>2) My server should not send 406, since it's only a SHOULD requirement
>anyway.  Or perhaps it should send 406 only for HTTP/1.1 requests.

If the above paper is available in ps.Z version only (so we don't have
content negotiation in the sense of multiple variants) I would never
send a 406.  The 1.1 spec says:

    Note: HTTP/1.1 servers are allowed to return responses which are
    not acceptable according to the accept headers sent in the request.
    In some cases, this may even be preferable to sending a 406

and your situation is one of the 'some cases'.  In your case I would
return the document with 

Content-type: application/x-compress  
      (MIME type from memory, I may be wrong)

which will probably result in the end user having to handle the
top-level .ps format by hand, but at least it will prevent
compressed data from being fed into a postscript helper application.

In fact I would say that, given the current installed base and if you
are aiming for maximum interoperability, if a server is in the
situation of only being able to send .ps.Z, it should always serve it
with the above content-type, and never with the
content-type/content-encoding values you mention above.  If it is
going to switch headers on a case by case basis, it should add the
appropriate headers to disable proxy caching.

Your scenario is really a case where a server has to choose between
evils: really fixing the problem involves having the content author
change the .ps.Z into .ps, or a choice between .ps and .ps.gz.

>Dave Kristol


Received on Tuesday, 3 November 1998 12:51:47 UTC