Here is another attempt to summarize the Chunking debate for the
Implementor's guide.
RFC2068 requires HTTP1.1 Servers to support both Content Length and
Chunking for all requests. HTTP1.1 was chosen (as opposed to HTTP1.0) as
the transport for IPP partly to facilitate large, indeterminate length
print jobs via Chunked encoding as an alternative to knowing the Content
Length.
CGI, on the other hand, mandates the presence of the CONTENT_LENGTH
environment variable.
Largely due to this HTTP1.1 / CGI conflict, HTTP1.1 server implementations
exist that do not support Chunking for the HTTP (IPP) POST.
It is encouraged that all IPP servers utilize HTTP1.1 servers that support
Chunking. Still, IPP clients must be warned that IPP servers may exist that
do not support Chunking. In this case, the IPP server will return error 411
(Length Required) in response to the HTTP POST.
Thus, all IPP clients are advised to support the ability to attempt to
determine CONTENT_LENGTH if error 411 is encountered in response to a
Chunked request.
In addition, some IPP servers may implement a filter-and-buffer approach to
determine CONTENT_LENGTH from a chunked encoding before passing the decoded
request body to the CGI application. If the buffered request grows too
large, the server MAY reject the request with status code 413 (Request
Entity Too Large). If this occurs, the IPP server MAY also close the
connection to prevent the client from continuing the request.
Harry Lewis - IBM Printing Systems
harryl at us.ibm.com