An HTTP POST operation is completely separate from CGI, and therefore
a 1.1 server MUST handle chunked input as required by the spec,
regardless if the method being used for the request is CGI, IPP, or
whatever.
> 2. MAY a server discard the message body of a POST request with no
> Content-Length when the destination resource is CGI?
I think the answer to this one must be NO.
> 3. MUST a server buffer the message body of a POST request with
> Transfer-Encoding: chunked and generate a CONTENT_LENGTH when the
> destination resource is CGI?
I think the answer to this one must be YES, since CGI 1.1 requires
a CONTENT_LENGTH.
> 4. SHOULD a server buffer the message body of a POST request with
> Transfer-Encoding: chunked and generate a CONTENT_LENGTH when the
> destination resource is CGI?
If #3 is true, then this one gets thrown out.
> What if the destination resource is a servlet?
That should probably be handled on a case-by-case basis. For
established methods like CGI I think we need to keep backwards
compatibility, but for new methods (IPP, etc.) they need to
handle streams of unspecified length. The transfer encoding of
the incoming data needs to be separated from the servlet, tho
(i.e. the HTTP server should handle unchunking and sending
either the whole unchunked request or chunk data as it is
recieved to the servlet).
> Should this information be written in a spec or informational
> something somewhere?
It definitely should be included in the finalized CGI 1.1 spec,
and maybe a note or two in the IPP implementation guide, too.
-- ______________________________________________________________________ Michael Sweet, Easy Software Products mike@easysw.com Printing Software for UNIX http://www.easysw.com