Thanks to Carl for writing the initial description and integrating the
comments we got last week,
Tom
>-----Original Message-----
>From: kugler@us.ibm.com [mailto:kugler@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@cp10.es.xerox.com> on 01/08/99 04:08:51 PM
>
>To: Carl Kugler/Boulder/IBM
>cc: ipp@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@us.ibm.com [mailto:kugler@us.ibm.com]
>>Sent: Thursday, January 07, 1999 07:27
>>To: CGI-WG@Golux.Com
>>Cc: ipp@pwg.org; http-wg@cuckoo.hpl.hp.com;
>>SERVLET-INTEREST@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
>>
>>
>
>
>