This does present the situation more clearly.
However, I would suggest two separate headed paragraphs in the Guide. One
relates to CGI and points out that CGI-based implementations may be non
complient with respect to chunking.
A second paragraph is a hint for clients, pointing out that some servers may
not implement chunking and that special actions may be taken to provide
compatability which such servers.
The suggested rewording follows.
Paragraph on Problems with the Use of CGI
RFC2068 requires HTTP1.1 Servers to support both Content Length and
Chunking for all requests. The use of chunking rather than determining
Content Length should facilitate the transmission of large, indeterminate
length print jobs.
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.
Paragraph on IPP Client Handling of Non-Chunking Servers
RFC2068 requires HTTP1.1 Servers to support both Content Length and
Chunking for all requests. However, some IPP servers may exist that
do not support Chunking. In this case, the IPP server may return error
411(Length Required) in response to the HTTP POST.
Further, 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 a 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.
To provide compatability with such servers, IPP clients MAY support the
ability to determine CONTENT_LENGTH and resubmit the job if error 411 or
error 413 is encountered in response to a Chunked request.
Bill Wagner