Sounds better.
I agree with your counter suggestion that we NOT recommend that clients
overcome non-conforming servers that don't receive and decode chunked
requests.
So lets go with your suggestion for clients, but add "(non-conforming)", so
we'd have::
Note: for CGI legacy reasons, some general-purpose web servers reject
chunked POST requests. To provide compatibility with such (non-conforming)
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.
However, for the server, I'm concerned that the IIG is somehow watering down
the conformance requirements of HTTP/1.1 and IPP/1.0, when the IIG uses the
phrases "strongly RECOMMEND" and "SHOULD"
be able to receive and decode HTTP/1.1 messages encoded with the "chunked"
transfer-coding?
Also as a nit, the IIG hasn't defined who "we" is.
So instead of your suggested sentence:
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.
How about:
In order to conform to IPP/1.0, IPP objects MUST be able to receive and
decode HTTP/1.1 messages encoded with the "chunked" transfer-coding.
Therefore, IPP/1.0, implementers that are using CGI scripts need to either
(1) use a web server that is able to receive and decode HTTP/1.1 chunked
POST requests or (2) use another implementation approach..
Comments?
Thanks,
Tom
>-----Original Message-----
>From: kugler@us.ibm.com [mailto:kugler@us.ibm.com]
>Sent: Thursday, January 21, 1999 10:14
>To: Hastings, Tom N
>Cc: Wagner,William; harryl@us.ibm.com; ipp@pwg.org
>Subject: RE: IPP> Chunking Explanation
>
>
>
>
>
>>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@cp10.es.xerox.com> on 01/21/99 02:19:54 AM
>
>To: "Wagner,William" <bwagner@digprod.com>, Harry
>Lewis/Boulder/IBM, Carl
> Kugler/Boulder/IBM, ipp@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.
>
>