2009/11/25 Edgar Frank <ef-li...@email.de>: >> On Tue, Nov 24, 2009 at 05:07 PM, Jeff Trawick <traw...@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
