IPP> Chunking Explanation

IPP> Chunking Explanation

Scott Lawrence lawrence at agranat.com
Thu Jan 21 13:57:58 EST 1999


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