httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edgar Frank <>
Subject Re: [mod_fcgid] Feedback / Suggestions
Date Wed, 25 Nov 2009 09:50:54 GMT
> On Tue, Nov 24, 2009 at 05:07 PM, Jeff Trawick <> 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
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.


View raw message