- From: Patrick McManus <mcmanus@appliedtheory.com>
- Date: Fri, 1 Aug 1997 14:09:04 -0400 (EDT)
- To: http working group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
- Cc: patrick mcmanus <mcmanus@appliedtheory.com>
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
Received on Friday, 1 August 1997 11:10:31 UTC