httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@kleber.ICS.UCI.EDU>
Subject Re: what to do about CGI and chunked
Date Thu, 21 Nov 1996 02:53:34 GMT
>>Apache is currently schizo in terms of how it treats CGI.  On the one hand,
>>it tries to treat CGI scripts as idiot children and protect them from
>>HTTP/1.1 improvements, which prevents new CGI scripts from using HTTP/1.1.
>>On the other hand, it does so in a way which is no longer compliant with
> I don't understand the issue.  Please help me.
> According to HTTP/1.1, transfer codings are applied in order to
> ensure "safe transport" through the network.  Safe transport
> seems like a server issue, not a script issue.  Why not simply
> present the entity-body to the CGI or FastCGI script?

Because CGI is a gateway mechanism, which may lead to another network
or cache or related mechanism that needs to know it received the whole
input message before taking the indicated action.  The only thing CGI/1.1
provides for that purpose is Content-Length.

> Surely the server can deal with Content-MD5 footers, or other
> footers as they are defined.

Yes, assuming they are not needed by the other side of the gateway.
But we cannot know that in general.

> The lack of a Content-Length presents one problem, namely
> how does the script detect that it has received the entire
> entity-body?  The alternatives for CGI seem to be:
>   * encode stdin in a tag-length-value format, forcing the CGI script
>     to parse this format.  define a tag that means "premature end
>     of entity-body".

That's what chunked encoding does.  Option (b) was to leave the stdin
encoded as it is pumped to the CGI, with the assumption being that old
CGI scripts will never be sent chunked stuff.

>   * have the server send a signal to the CGI script if the entity-body
>     is not received intact. Otherwise send no signal and mark the
>     end of the entity-body by sending EOF on stdin.

Such inter-process communication is difficult, and CGI/1.1 does not
guarantee that stdin will be closed when the input is complete.  That is
why well-written post scripts require content-length to be passed rather
than just looking for EOF.

> For FastCGI, since the client is already doing protocol interpretation,
> it would be straightforward enough to define a new record type
> that means "premature end of entity-body," and modify the client
> library to deal with this.

That would correspond to what my last patch to get_client_block would do --
remove the chunking and return -1 if it ends prematurely.  Perhaps what
we should do is create two versions of get_client_block, one that unchunks
and another that does not.


View raw message