IPP> Chunking Explanation

IPP> Chunking Explanation

IPP> Chunking Explanation

Hastings, Tom N hastings at cp10.es.xerox.com
Fri Jan 22 11:26:05 EST 1999


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



More information about the Ipp mailing list