httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brown <mbr...@openmarket.com>
Subject Re: what to do about CGI and chunked
Date Fri, 22 Nov 1996 00:10:04 GMT
At 06:53 PM 11/20/96 -0800, Roy T. Fielding wrote:
>> 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.

Thanks for the reply.
I agree that some replacement for Content-Length is required.

>> 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 gateway can always regenerate them if it decides it needs to chunk
on the other side.

>> 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.

This is the assumption that I don't understand.  If this chunking stuff
is useful I'd expect lots of old scripts to see it.  The challenge would
be to let them see it with minimal modifications.

Perhaps there are some assumptions about what chunking is good for
that I don't understand.

>>   * 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.

Signals are ugly but I'm not sure I know what you mean by
"difficult".  Is there an OS that matters that doesn't
allow a parent process to interrupt its child?  Only the most
trivial signal handler is needed: one that sets a bit
that will be tested only when there's no risk of the signal
going off (i.e. after EOF has been seen).

What CGI/1.1 guarantees isn't the real point.  There is no
way for old scripts to behave correctly without *some*
modification, since Content-Length is gone.
The only question is, how much will the old scripts have to be
modified?  Most script-writers would be pretty happy to be able
to ignore Content-Length, pull on stdin until EOF, and then test
a bit to see if the entity-body was truncated.

In the 1.2 timeframe, however, perhaps all that's possible
is to pass the chunked encoding through to the script and
let the script deal with it, i.e. your option (b).

    --mark


Mime
View raw message