Re: Implementation Experience Content Encoding

In a previous episode Scott Lawrence said...
:: 
:: 
:: >>>>> "PM" == Patrick McManus <mcmanus@appliedtheory.com> writes:
:: 

:: PM> consider an http/1.1 server that receives this request
:: 
:: PM> HEAD /m013/compressfly.cgi?file=idhm&style=gzip HTTP/1.0

(that's meant to be "GET")

:: 
:: 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>
:: 
::   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...
:: 

don't worry about what the URL means.. it's just a test scenario to
force some different behaviorial choices.. you are correct that it's
kind of contrived.. but test cases can be like that.


::   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:

:: Content-Type: application/x-gzip

That's nice for you, but my content has a type of text/plain so I want
to label it like that.  14.3 of the current draft tells me

            If no Accept-Encoding field is present in a request, the
            server MAY assume that the client will accept any content
            coding.  In this case, if "identity" is one of the available
            content-codings, then the server SHOULD use the "identity"
            content-coding, unless it has additional information that a
            different content-coding is meaningful to the client.

            Note: If the request does not include an Accept-Encoding
            field, and if the "identity" content-coding is unavailable,
            then preference should be given to content-codings commonly
            understood by HTTP/1.0 clients (i.e., "gzip" and
            "compress"); some older clients improperly displaymessages
            sent with other content-encodings.  The server may alsomake
            this decision based on information about the particular
            user-agent or client.

and I don't have an identity version of my resource hanging
around.. (I deleted it because in this bizarre case disk space is
mighty precious) so I sent back gzip and all hell broke loose on a
couple mighty popular windows browsers.

So am I doing something wrong, or is the spec misleading with its
note?

-P

Received on Friday, 1 August 1997 11:41:39 UTC