W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

Implementation Experience Content Encoding

From: Patrick McManus <mcmanus@appliedtheory.com>
Date: Fri, 1 Aug 1997 14:09:04 -0400 (EDT)
Message-Id: <199708011809.OAA03725@pat.appliedtheory.com>
To: http working group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Cc: patrick mcmanus <mcmanus@appliedtheory.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4056
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?

Received on Friday, 1 August 1997 11:10:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:20 UTC