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

Re: Any objections to "Accept-encoding: gzip, *;q=0"?

From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
Date: Thu, 24 Jul 1997 15:06:16 -0700
To: Larry Masinter <masinter@parc.xerox.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <9707241520.aa24741@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3908
>If you merely look at the specifications, there is enough
>evidence that HTTP/1.0 had intended the "accept*" headers
>to be consistent and that the distinctions in HTTP/1.1 were
>merely editorial oversight because different people wrote
>different parts. From that point to not require a burden
>of proof in order to reinstate consistency.

Sorry, that's nonsense.  The specifications are different because
the implementations are different.  Henrik and I spent well over a
year looking at different implementations in order to derive the
syntax for each header field -- had they been the same, we would have
been overjoyed to use a single syntax.  The most painful thing about
the HTTP spec work was dealing with shortsighted designs and then
having to explain them to others.

There is no q-value for Accept-Encoding because the following two
fields are not equivalent

   Accept-Encoding: x-gzip;q=1, x-compress;q=1

   Accept-Encoding: x-gzip, x-compress

for any of the existing server implementations of HTTP/1.x.
It is therefore wrong for the specification to suggest that it would be.

If such a change is made, then there must also be a requirement (not a note)
that prevents the use of a q-value with any encoding other than identity.
Otherwise, you will have changed the protocol.

Received on Thursday, 24 July 1997 15:29:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:20 UTC