Carl,
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 at us.ibm.com [mailto:kugler at us.ibm.com]
>Sent: Thursday, January 21, 1999 10:14
>To: Hastings, Tom N
>Cc: Wagner,William; harryl at us.ibm.com; ipp at 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 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.
>>