Scott-
You're right, of course. This language was added to the IPP spec back
when the http-v11-spec was at about rev 03. At that time, "TE: indentity"
would have had the effect described. It actually works on some servers I've
tried.
draft-ietf-http-v11-spec-rev-03:
3.6.2 Identity Transfer Coding
The identity transfer-encoding is the default (identity) encoding;
the use of no transformation whatsoever. The identity transfer-coding
is used only in the TE header field, and SHOULD NOT be used in any
Transfer-Encoding header field.
-Carl
<36a778b6.3dad331- at agranat.com> wrote:
Original Article: http://www.egroups.com/list/ipp/?start=5144
>> This discussion (and a consultation with one of my customers) brought to my
> attention a problem in the IPP Implementors Guide [1]:
>> > 3.6 HTTP/1.1 Chunking
> >
> >
> > Clients MUST anticipate that the HTTP/1.1 server may chunk responses and
> > MUST accept them in responses. However, a (non-conforming) HTTP client
> > that is unable to accept chunked responses may attempt to request an
> > HTTP 1.1 server not to use chunking in its response to an operation by
> > using the following HTTP header:
> >
> > TE: identity
>> The 'identity' value is not a valid token in the 'TE' request header field,
> and will not have the effect described.
>> From the current HTTP/1.1 I-D [2]:
>> > 14.39 TE
> >
> > The TE request-header field indicates what extension transfer-codings
> > it is willing to accept in the response and whether or not it is
> > willing to accept trailer fields in a chunked transfer-coding. Its
> > value may consist of the keyword "trailers" and/or a comma-separated
> > list of extension transfer-coding names [...]
> ^^^^^^^^^^^^^^^^^^^^^
>> The 'identity' token is a content-coding name, _not_ a transfer-coding
> name.
> A little further down in the same section:
>> > A server tests whether a transfer-coding is acceptable, according to
> > a TE field, using these rules:
> >
> > 1.
> > The "chunked" transfer-coding is always acceptable. [...]
>> There is _no_ mechanism in HTTP/1.1 for a client to indicate that it is
> unable to accept chunked encoding in a response. The use of the 'HTTP/1.1'
> version identifier on the Request-line indicates willingness to accept
> chunked responses. The 'TE' header can be used (as described in section
> 14.39 of [2]) to indicate that a client does not accept trailers sent
> _after_ the last chunk, but cannot be used to disable chunking.
>> For our server, if the client sends 'HTTP/1.0' in the HTTP-Version, the
> server will disable chunking in the response and if the length of the
> response is indeterminate it will revert to closing the connection to
> indicate the end of the response (which is what a 1.0 client expects).
>> References:
> [1]
>http://www.ietf.org/internet-drafts/draft-ietf-ipp-implementers-guide-00.txt> [2] http://www.ietf.org/internet-drafts/draft-ietf-http-v11-spec-rev-06.txt>> --
> Scott Lawrence Director of R & D <lawrence at agranat.com>
> Agranat Systems, Inc. Embedded Web Technology http://www.agranat.com/