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

• Messages sorted by: [ date ][ thread ][ subject ][ author ]
• Next message: Jeffrey Mogul: "Re: CONTENT-ENCODING: FIXED revised proposed wording"
• Previous message: Jeffrey Mogul: "Proposed resolution for IDEMPOTENT issue"
• In reply to: Larry Masinter: "Re: Any objections to "Accept-encoding: gzip, *;q=0"?"

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

.....Roy

• Next message: Jeffrey Mogul: "Re: CONTENT-ENCODING: FIXED revised proposed wording"
• Previous message: Jeffrey Mogul: "Proposed resolution for IDEMPOTENT issue"
• In reply to: Larry Masinter: "Re: Any objections to "Accept-encoding: gzip, *;q=0"?"