>
>> Many http server implementors seem to have interpreted the combinati=
on
>> of these requirements to imply that a POST request without a
>> Content-Length HTTP header cannot have a message-body. Which furthe=
r
>> 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 a=
nd
>> in all cases, a servlet or CGI program gets end-of-file as soon as i=
t
>> tries to read the message-body input stream for a POST request with
>> chunked transfer-coding. However, there are some web servers out th=
ere
>> 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 PO=
STs
>> are considered broken, and have to be fixed to buffer a chunked requ=
est
>> 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 und=
er
that is unspecified, although the IPP/1.0: Implementer=92s Guide
(ftp://ftp.pwg.org/pub/pwg/ipp/proposed-clarifications/ipp-implementers=
-gui
de-981206-rev.pdf) does say this: "The IPP layer doesn=92t have to dea=
l 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 chan=
ge
>> 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.
=