kugler at us.ibm.com wrote:
>> To wrap up this discussion, can we summarize the answer in RFC 2119
> standard-speak? What requirements must an http server meet in order
> to claim compliance with HTTP/1.1 AND CGI/1.1?
>> 1. MAY a server discard the message body of a POST request with no
> Content-Length?
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 at easysw.com
Printing Software for UNIX http://www.easysw.com