- From: Scott Lawrence <lawrence@agranat.com>
- Date: Fri, 01 Aug 1997 14:22:43 -0400
- To: mcmanus@appliedtheory.com
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>>>>> "PM" == Patrick McManus <mcmanus@appliedtheory.com> writes: PM> I've reached a point of frustration with content encoding.. PM> consider an http/1.1 server that receives this request PM> HEAD /m013/compressfly.cgi?file=idhm&style=gzip HTTP/1.0 PM> and generates this response PM> HTTP/1.1 200 OK PM> Date: Fri, 01 Aug 1997 17:46:27 GMT PM> Server: ATCm005/1.0d PM> Content-Encoding: gzip PM> Connection: close PM> Content-Type: text/plain PM> << whole bunch of gzip encoded plain text here>> PM> <close of connection> First of all, there should be no body in response to a HEAD request, but assuming that you meant GET, there is still the issue that you've apparently taken instructions from the human user here. Presumably the 'file' and 'style' parameters came from a form, and the user selected 'gzip' from a menu; the compressfly.cgi program just did as it was told... If I were writing such a script, I would check for the presence of an Accept-Encoding header which included 'gzip'; finding one, I would send the response you show above and expect it to work. Without one, I would send: HTTP/1.1 200 OK Date: Fri, 01 Aug 1997 17:46:27 GMT Server: ATCm005/1.0d Connection: close Content-Type: application/x-gzip << whole bunch of gzip encoded plain text here>> <close of connection> and let the browser do whatever it does with the gzip mime type. -- Scott Lawrence EmWeb Embedded Server <lawrence@agranat.com> Agranat Systems, Inc. Engineering http://www.agranat.com/
Received on Friday, 1 August 1997 11:31:49 UTC