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

Re: Implementation Experience Content Encoding

From: Patrick McManus <mcmanus@appliedtheory.com>
Date: Fri, 1 Aug 1997 16:19:57 -0400 (EDT)
Message-Id: <199708012019.QAA04404@pat.appliedtheory.com>
To: Scott Lawrence <lawrence@agranat.com>
Cc: mcmanus@appliedtheory.com, lawrence@agranat.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
In a previous episode Scott Lawrence said...
:: 
:: 
:: >>>>> "PM" == Patrick McManus <mcmanus@appliedtheory.com> writes:

:: 
:: PM>             If no Accept-Encoding field is present in a request, the
:: PM>             server MAY assume that the client will accept any content
:: PM>             coding....
:: 
:: PM> and I don't have an identity version of my resource hanging
:: PM> around.. (I deleted it because in this bizarre case disk space is
:: PM> mighty precious) so I sent back gzip and all hell broke loose on a
:: PM> couple mighty popular windows browsers.
:: 
:: PM> So am I doing something wrong, or is the spec misleading with its
:: PM> note?
:: 
::   The spec says you MAY assume that the client will accept any
::   encoding; it doesn't promise that will work, or place any
::   requirement on clients to do anything about it.  

you're quite right that it doesn't _promise_ anything. It does however
say _more_ than just the 'MAY assume' part.. this is from 14.3:

            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 display messages
            sent with other content-encodings.  The server may also make
            this decision based on information about the particular
            user-agent or client.

this to me says that in no uncertain terms, common 1.0 clients support
gzip and compress. If that doesn't include netscape for windows then
we need to work on our definition of 'commonly understood'.

here's the rub: UA's sending the accept-encoding header is a rarer
thing than them being able to decode the corresponding
content-encoding.. ns for unix doesn't send the header, but it can do
the decoding fine.. ns and msie for windows don't send the header and
seem to struggle with decoding.. lynx both sends the header and
decodes it (what a concept!)..

I understand that this is sort of the way of life, and maybe a UA
matrix is what I have to live with in the server code (as the last
sentence of the note mentions) but from a --working group
perspective-- we have a spec that offers implementation advice (the
note: ) that I've found inaccurate wrt current practice.

::  If I were you I'd
::   add gunzip-on-the-fly to my server so that you can send real
::   text/plain.

oh, it's there.. I'd just like to avoid using it when I can ;)

thanks for your help,
-P
Received on Friday, 1 August 1997 13:21:38 EDT

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