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

Re: Implementation Experience Content Encoding

From: Scott Lawrence <lawrence@agranat.com>
Date: Fri, 01 Aug 1997 14:22:43 -0400
Message-Id: <199708011822.OAA09571@devnix.agranat.com>
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 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:50 EDT