httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Dumpleton <graham.dumple...@gmail.com>
Subject Re: [mod_fcgid] Feedback / Suggestions
Date Wed, 25 Nov 2009 10:03:22 GMT
2009/11/25 Edgar Frank <ef-lists@email.de>:
>> On Tue, Nov 24, 2009 at 05:07 PM, Jeff Trawick <trawick@gmail.com> wrote:
>> >>> Or otherwise, can someone explain the details to me why it is as it
is?
>> >>> Especially in terms of not pipeling data directly (maybe after a little
>> >>> buffering to build proper FCGI packets)? The comment in
>> >>> fcgid_bridge.c:452 (add_request_body) left me clueless. Why would this
>> >>> keep the server in processing too long? Processing takes its time either
>> >>> way, I'd assume. Looking forward to enlightment. :)
>> >>
>> >> I can only guess that the problem at hand when this was implemented
>> >> was that some backend application processes were so expensive that
>> >> that they couldn't be tied up until all data had been read from slow
>> >> clients.
>> >>
>> > Yes, Jeff is right :)
>>
>> This is a reasonable feature; once streaming to the app is implemented
>> this alternate mechanism can be enabled with a per-request envvar
>> (e.g., SetEnv in the directory or location).
>
> Thanks for explaining this to me.
>
> While delving into the FCGI and CGI spec, I encountered another reason not to
> stream client data directly. CGI wants an explicitly set CONTENT_LENGTH and
> FCGI enforces than rather obsoletes this (last sentence in 6.2 of the FCGI
> spec).
> If the client sends for any reason a message body with no CONTENT_LENGTH set
> or CONTENT_LENGTH to be ignored as defined by RFC2616, you have to read the
> full message body to determine the correct content length which should be
> transferred to the backend.

Things can get worse. Even if CONTENT_LENGTH is sent, if you have
requests with compressed content which is decompressed by mod_deflate,
the amount of content will not actually match what CONTENT_LENGTH says
there will be as it reflects how things are before content is
decompressed.

Don't know about FASTCGI in general, but for WSGI (Python higher level
interface that can sit on CGI or FASTCGI) they have the stupid
requirement that you take CONTENT_LENGTH as being precise and that you
must not read more than CONTENT_LENGTH. If CONTENT_LENGTH isn't
provided, WSGI says you are supposed to take it as meaning no data.

For WSGI at least, means you can't have mutating input filters unless
the input filter buffers up all the request content after doing what
it does and recalculates CONTENT_LENGTH and sends through modified
value. In practice input filters don't do this.

Anyway, don't know if this is at all relevant to FASTCGI. As you point
out though, the CONTENT_LENGTH requirement does at least prevent
FASTCGI from handling chunked request content. WSGI specification has
same stupid limitation.

If things were defined so as to simply read until all input exhausted
and for CONTENT_LENGTH really only to be used as a hint or in
determining if original request body may be too large, wouldn't be
such a pain.

Graham

Mime
View raw message