IPP> Chunking Explanation

IPP> Chunking Explanation

IPP> Chunking Explanation

kugler at us.ibm.com kugler at us.ibm.com
Thu Jan 21 14:59:13 EST 1999


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

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.


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

More information about the Ipp mailing list