Implementation Experience Content Encoding
Patrick McManus (mcmanus@AppliedTheory.com)
Fri, 1 Aug 1997 14:09:04 -0400 (EDT)
I've reached a point of frustration with content encoding..
consider an http/1.1 server that receives this request
HEAD /m013/compressfly.cgi?file=idhm&style=gzip HTTP/1.0
and generates this response
HTTP/1.1 200 OK
Date: Fri, 01 Aug 1997 17:46:27 GMT
Server: ATCm005/1.0d
Content-Encoding: gzip
Connection: close
Content-Type: text/plain
<< whole bunch of gzip encoded plain text here>>
<close of connection>
----
the problem is that the windows versions of msie and netscape (version
4 for both) aren't able to remove that encoding and show the
text/plain underneath.. (netscape show's the gzip content, and msie
gives an error message)... a content-Encoding of x-gzip doesn't change
the behavior.. UNIX versions of netscape and lynx don't seem to have a
problem... this run contrary to the "Note" of 14.3 in draft 8 that
calls "gzip" and "compress" commonly understood content-codings by
HTTP/1.0 clients (which are to be viable alternatives if there is no
Accept-Encoding field present in the request)..
Now I'd always thought that note was correct in practice, but the
above indicates otherwise.. anybody know what the
state-of-the-industry is here?
-P