Re: TE: identity; q=0

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.
    
    Consider:  The HTTP/1.1 spec. already says that "chunked" is always
    acceptable.  If "identity" were also always acceptable, then any server
    that just implements those two (a common case?) could ignore the TE
    header altogether, thus saving processing and code space.
    
    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 example, the client might be paying based on bytes received, and
would rather give the user a chance to intervene before doing a
large and expensive transfer.  (This is my recollection of the
theory behind this.)  If delta-encoding ever becomes widely
used, the difference in cost is potentially even larger than with
compression.

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.

-Jeff

Received on Wednesday, 29 April 1998 15:46:45 UTC