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
>> which is compounded by the Internet Printing Protocol (IPP) Spec (see
>>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
>>> 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
>>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
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
That's an implementation decision. IPP uses HTTP, and what goes on under
that is unspecified, although the IPP/1.0: Implementer’s Guide
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
>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