Ken Coar wrote:
>Carl Kugler wrote:
>>>> I've stumbled across an apparent conflict between the CGI spec (see
>>http://www.ietf.org/internet-drafts/draft-coar-cgi-v11-00.txt) and the
>> HTTP/1.1 spec (see
>>http://www.ietf.org/internet-drafts/draft-ietf-http-v11-spec-rev-06.txt)
>> which is compounded by the Internet Printing Protocol (IPP) Spec (see
>>http://www.ietf.org//internet-drafts/draft-ietf-ipp-protocol-07.txt).
>>Actually not, though I can see why it would look that way.
>There are two reasons:
>>The first is philosophical: this CGI draft is describing
>current practice, not how things *ought* to be. (We're
>saving that for the CGI/1.2 spec, which will begin as soon
>as we send this one in for RFChood.)
>>The second is implementation: The script is not the direct
>recipient of the HTTP stream. Rather, an HTTP server is the
>intermediary, and it has the (currently unstated) responsibility
>to undo any Transfer-Encoding before passing the data to the script.
>So if there's a message-body, chunked or not, the server
>must provide it to the script as a monolithic unchunked
>block, and provide the CONTENT_LENGTH metavariable to
>communicate the block's size.
I think it would be a good idea to state this explicitly somewhere in the
specs.
>>> Many http server implementors seem to have interpreted the combination
>> of these requirements to imply that a POST request without a
>> Content-Length HTTP header cannot have a message-body. Which further
>> implies that a POST using Transfer-Encoding: chunked cannot have a
>> message-body.
>>I believe that is an incorrect interpretation. There aren't
>that many truly compliant (even conditionally) HTTP/1.1 clients
>or servers out there. Section 4.4 describes how Transfer-Encoding
>dominates if both fields are present in a request, and that
>a Content-Length field is *required* unless the client is certain
>the server is HTTP/1.1 compliant.
>>> Indeed, I have tried several commercial web servers and
>> in all cases, a servlet or CGI program gets end-of-file as soon as it
>> tries to read the message-body input stream for a POST request with
>> chunked transfer-coding. However, there are some web servers out there
>> that do work with chunked POSTs.
>>Then they're not playing by the rules. (Have you tried Apache, by the
>way?)
A group here tried it and said that Apache does not support POST with
chunked data. Personally, I tried Apache with the JRun servlet runner (on
NT) and found that my servlet got no message-body data.
> The script does not read from the socket, it reads from the
>server. If the server has hooked the socket up directly to the
>script's input stream, it's following NPH rules and all bets are
>off. Or else it's broken, since it can't be supplying the required
>metadata to the script. (Off the top of my head.)
>>> 1. No spec changes. HTTP/1.1 servers that don't support chunked POSTs
>> are considered broken, and have to be fixed to buffer a chunked request
>> message-body in order to generate a CONTENT_LENGTH.
>>You're confusing CGI-brokenness with HTTP/1.1-brokenness.
>If they speak HTTP/1.1 correctly, they're compliant that
>way -- but if they don't take the necessary steps (i.e.,
>recompose a chunked message) to provide the required
>metadata to the script, they're not CGI-compliant.
>>Does IPP use CGI, or does it interface to the server in some other
>way?
That's an implementation decision. IPP uses HTTP, and what goes on under
that is unspecified, although the IPP/1.0: Implementer’s Guide
(ftp://ftp.pwg.org/pub/pwg/ipp/proposed-clarifications/ipp-implementers-gui
de-981206-rev.pdf) does say this: "The IPP layer doesn’t have to deal with
chunking. In the context of CGI scripts, the HTTP layer removes any
chunking information in the received data."
>>> 2. Change CGI spec to remove dependency on CONTENT_LENGTH (and change
>> http servers accordingly).
>>No way is that going to happen, at least not for CGI/1.1.
>It's not current practice. Maybe CGI/1.2, but that's open
>to debate.
>This same problem affects Java servlets. But the servlet API spec is
silent about it.
>> In any case, I think we need some clarification on this issue. Are
>> POSTs with message bodies and without Content-Length headers legal?
>>It's clearly stated: the server MUST provide a CONTENT_LENGTH
>metavariable to the script. It's up to the server how it
>derives that value; at the moment, it means buffering chunked
>transfers.