W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1998

Re: TE: identity; q=0

From: Dave Kristol <dmk@bell-labs.com>
Date: Thu, 30 Apr 1998 09:52:46 -0400
Message-Id: <3548822E.DF7@bell-labs.com>
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: http-wg@cuckoo.hpl.hp.com
Jeffrey Mogul wrote:
> 
> Dave Kristol writes:
> 
>     So, I'm thinking about implementing this, and it occurs to me that it's
>     crazy to allow TE: identity; q=0.
>     [...]
>     Most content gets returned as "identity".  But as the spec. now stands,
>     a fully conforming server must check the TE header for "identity; q=0",
>     just so it knows to return a 406 (Not Acceptable).  That seems crazy to
>     me.  What earthly reason could a client have for *not* accepting
>     identity?
> 
> We had a similar discussion around Accept-Encoding several years ago.
> 
> The reason for a client to say "I don't want you to send me an
> identity content-coding" was that it would presumably be doing
> this in a context where compression was not only acceptable but
> also highly desirable.  E.g.,
> 
>         Accept-Encoding: gzip, identity; q=0
> [...]
> For transfer-coding, the situation is made murkier by the requirement
> that "chunked" is always acceptable.  This means that a client sending
> 
>         TE: gzip, identity; q=0
> 
> in hopes of getting a compressed result, or nothing, could legally
> be sent a response that is chunked but not compressed (i.e., even
> more bytes than the identity encoding!)  And you can't even say
> something like
> 
>         TE: gzip, identity; q=0, chunked; q=0
> 
> to force the use of gzip, because we're requiring the use of
> "chunked" with any non-identity transfer-coding.
> 
> In short, the rationale that applied to Accept-Encoding probably
> does not apply here.  I'm not 100% sure that there might not be
> another rationale (for TE) that someone had in mind, though.

In the Accept-Encoding case, the client declares what it does and does
not understand, and it gives preferences.  In the TE case it does the
same.  But as you point out, the alternative to "identity" may be even
more bytes (using "chunked"), and the goal of reduced bytes transferred
will have been thwarted.  And I don't think there's any question that a
client can understand "identity" in all circumstances.

I propose changing the wording so "identity" is always acceptable, just
like chunked.  The presence of q=0 (or q=0.001) would clue the server
that an alternative (as in your second TE example above) is really,
really, preferred, but not mandatory.

[This raises a related question for Accept-Encoding:  does it really
make sense to suppress "identity" with "q=0"?  Wouldn't it be better to
receive the content without an encoding than not to receive it at all?]

Dave Kristol
Received on Thursday, 30 April 1998 06:58:19 EDT

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