I like Bill's suggestions on Harry's original.
1. I'd like to clarify the last paragraph of the first section to make sure
that its HTTP POST chunked requests that we are talking about. (Some
implementations support chunked GET responses, but not chunked POST
requests).
So change:
It is encouraged that all IPP servers utilize HTTP1.1 servers that support
chunking.
to:
It is encouraged that all IPP servers utilize HTTP1.1 servers that support
chunking of POST requests.
2. In addition, I'd like to make the last paragraph of the second section to
be an encouragement, just like the last paragraph of the first section,
rather than just a MAY. What do you think?
So change:
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.
to:
To provide compatability with such servers, it is encouraged that IPP
clients 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.
Ok?
Tom Hastings
Here is Bill's complete text:
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/ipp/attachments/19990121/ffab769c/attachment-0001.html