IPP Mail Archive: RE: IPP> Chunking Explanation

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. =