Here is the integrated text for the IPP Implementer's Guide regarding
Chunked POST and CGI Scripts. Please send any comments. Is this the agreed
situation? I'm putting this text into the IPP Implementor's Guide for
distribution on Tuesday, 1/12.
Thanks to Carl for writing the initial description and integrating the
comments we got last week,
Tom
>-----Original Message-----
>From: kugler at us.ibm.com [mailto:kugler at us.ibm.com]
>Sent: Friday, January 08, 1999 16:24
>To: Hastings, Tom N
>Subject: RE: IPP> Chunked POST: SUMMARY
>>>>>Tom-
>>I'm still not sure there is complete agreement about all
>these. But this
>is what I have at this point.
>>Here is an updated summary:
>>>About chunked POST in HTTP/1.1:
>>1. All HTTP/1.1 applications that receive entities MUST accept the
>"chunked" transfer-coding, thus allowing this mechanism to be used for
>messages when the message length cannot be determined in advance.
>2. However, an origin server MAY refuse to accept a request without a
>defined Content-Length by responding with status code 411 (Length
>Required).
>3. The Content-Length header field MUST NOT be sent if a
>Transfer-Encoding
>header field is present.
>4. An origin server acting as a CGI 1.1 gateway for a request MUST
>determine and set the CONTENT_LENGTH metavariable.
>5. There is currently nothing in the HTTP, CGI, or servlet specs to
>guarantee that origin servers will remove the Transfer-Encoding before
>passing a request body to a plug-in, servlet, (Fast)CGI, or across any
>other gateway boundary.
>>Origin servers supporting CGI 1.1 have two options when
>receiving a POST
>request with "Transfer-Encoding: chunked" for a CGI 1.1 resource:
>1. Reject the request with 411 (Length Required).
>2. Filter and buffer the request to determine CONTENT_LENGTH before
>passing the decoded request body to the CGI application. If
>the buffered
>request grows too large, the server MAY reject the request
>with status code
>413 (Request Entity Too Large) and the server MAY close the
>connection to
>prevent the client from continuing the request.
>>Origin servers supporting the Servlet API 2.1 have three options when
>receiving a POST request with "Transfer-Encoding: chunked" for
>a servlet
>resource:
>1. Reject the request with 411 (Length Required).
>2. Filter and buffer the request to determine CONTENT_LENGTH before
>passing the decoded request body to the servlet. If the
>buffered request
>grows too large, the server MAY reject the request with status code 413
>(Request Entity Too Large) and the server MAY close the connection to
>prevent the client from continuing the request.
>3. Pass a filtered input stream to the servlet and filter the
>request body
>on-the-fly to remove the chunked transfer-coding. Indicate
>the end of the
>request body with EOF (end of file) on the servlet input stream.
>>Implications for IPP:
>1. Chunking takes place in the transport layer, and is not
>part of the IPP
>protocol itself. In the context of CGI scripts, the HTTP layer either
>rejects a chunked POST request with 411 or removes any
>chunking information
>in the received data and supplies CONTENT_LENGTH. The CGI/1.1
>spec doesn't
>explicitly state that the HTTP server is required to decode the
>transfer-coding before passing the request body to the CGI
>application, but
>this behavior is virtually guaranteed by the massive install
>base of old
>CGI scripts in the world.
>>>2. The HTTP/1.1 standard does not guarantee that an origin server will
>accept chunked requests, regardless of the resource identified in the
>request.
>>>References:
>>>1. CGI/1.1
>(http://www.ietf.org/internet-drafts/draft-coar-cgi-v11-00.txt)
>>>2. HTTP/1.1 (
>http://www.ietf.org/internet-drafts/draft-ietf-http-v11-spec-re>v-06.txt)
>3. The Internet Printing Protocol (IPP/1.0) (
>http://www.ietf.org//internet-drafts/draft-ietf-ipp-protocol-07.txt)
>>>4. Servlet Specification Version 2.1
>(http://java.sun.com/products/servlet/2.1/index.html)
>>>> - Carl Kugler
>>>>>>>>"Hastings, Tom N" <hastings at cp10.es.xerox.com> on 01/08/99 04:08:51 PM
>>To: Carl Kugler/Boulder/IBM
>cc: ipp at pwg.org>Subject: RE: IPP> Chunked POST: SUMMARY
>>>>>>Carl,
>>You've done a great job in writing up the Chunked material. Can you
>integrate the recent messages into your original description,
>so I can put
>it into the Implementer's Guide the first of next week?
>>Thanks,
>Tom
>>>-----Original Message-----
>>From: kugler at us.ibm.com [mailto:kugler at us.ibm.com]
>>Sent: Thursday, January 07, 1999 07:27
>>To: CGI-WG at Golux.Com>>Cc: ipp at pwg.org; http-wg at cuckoo.hpl.hp.com;
>>SERVLET-INTEREST at JAVA.SUN.COM>>Subject: Re: IPP> Chunked POST: SUMMARY
>>>>>>>>>>Ross Patterson wrote:
>>>>>>> All HTTP/1.1 applications that receive entities MUST accept the
>>>>> "chunked" transfer-coding (section 3.6), thus allowing
>>this mechanism
>>>>> to be used for messages when the message length cannot be
>>determined
>>>>> in advance.
>>>>>>>>Apparently that should be interpreted as "MUST accept the 'chunked'
>>>>TRANSFER-CODING, but NEED NOT accept REQUESTs with that
>>transfer-coding."
>>>>>Correct - all HTTP 1.1 servers must be able to process
>>requests encoded
>>>as chunked data, but they are still allowed to refuse the request for
>>>other reasons.
>>>>To me, the presence of the 411 status code means that an
>>HTTP/1.1 server
>>MAY refuse to accept a request for the specific reason that
>>entity body is
>>encoded with the "chunked" transfer-coding:
>>>>411 Length Required
>>The server refuses to accept the request without a defined
>>Content-Length.
>>The client MAY repeat the request if it adds a valid
>>Content-Length header
>>field containing the length of the message-body in the
>request message.
>>>> -Carl
>>>>>>>