>Here is a summary of the responses that I received to my queries about
>chunked POST in HTTP/1.1.
>
>...
>5. Origin servers MUST remove the Transfer-Encoding before passing a
>request body to a plug-in, servlet, (Fast)CGI, or across any other gateway
>boundary.
That's not clearly stated in either the HTTP 1.1 or CGI 1.1 specifications.
I'll grant that it makes good sense though. HTTP requires that gateways
to MIME-compliant protocols remove transfer-codings (HTTP 1.1 rev 6 sec.
19.4.6), but HTTP doesn't assume a separate HTTP-protocol engine and a
program interacting with it according to the CGI protocol. As far as
HTTP is concerned, they might jointly comprise the "gateway", and the CGI
program might be responsible for removing any transfer-codings.
>Implications for IPP:
>1. The IPP layer doesn't have to deal with chunking. 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.
I'm not up on IPP, but I don't think you can blindly say that, given the
above.
>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.
HTTP actually doesn't guarantee anything about *acceptance* of requests.
There are lots of conditions that can provoke responses other than
"200 OK". It does, however, require that all HTTP 1.1 applications be
able to receive and decode chunked requests (HTTP 1.1 rev 6, sec. 3.6.1).
If the resource in question is implemented via CGI 1.1, it might still
be rejected as you noted due to buffering concerns, but if it is
implemented via an interface that does not require a pre-determined
length, there's nothing wrong with sending chunked data.
Ross Patterson
VM Software Division
Sterling Software, Inc.