>It is encouraged that all IPP servers utilize HTTP1.1 servers that support
chunking of POST requests.
I think we need a real technical writer on the team (i.e., someone who
majored in English)! I can just hear my old teachers shouting "Clunker!".
Passive voice, use of a big word "utilize" when "use" would suffice, poorly
defined notion of "support", IPP server is undefined, ... [Sorry about the
rant! No intent to offend anyone! I'm just as bad, which is why we need
an English major.]
How about something along the lines of:
> We strongly RECOMMEND that all IPP/1.0 applications be able to receive
and decode HTTP/1.1 messages encoded with the "chunked" transfer-coding.
Specifically, IPP objects SHOULD be able to receive and decode chunked POST
requests.
I'd rather leave 2 as a MAY rather than an "encouragement". I don't want
to encourage dependency on this kind of behavior. In many cases it's just
not practical for the client to buffer a dynamically-generated document
(e.g., network computers with limited resources). It's also quite
difficult, in some situations, to "back up" the content producer to retry
the request with Content-Length. How about something like this:
> Note: for CGI legacy reasons, some general-purpose web servers reject
chunked POST requests. To provide compatability with such servers, IPP
clients MAY support the ability to repeat a request with a valid
Content-Length header instead of the "chunked" transfer-coding when error
411 or error 413 is encountered.
-Carl
"Hastings, Tom N" <hastings at cp10.es.xerox.com> on 01/21/99 02:19:54 AM
To: "Wagner,William" <bwagner at digprod.com>, Harry Lewis/Boulder/IBM, Carl
Kugler/Boulder/IBM, ipp at pwg.org
cc:
Subject: 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.
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/fa56d021/att-1.htm