On Tue, Nov 24, 2009 at 10:50 AM, pqf <p...@mailtech.cn> wrote: >>> (3) >>> mod_fcgid currently buffers the complete input from the client >>> (occasionaly in a temp-file if the request is large) before it passes it >>> through to a FCGI backend. Could this be made configurable in a way like >>> File|Memory|Pipeline? (file - as is | memory - buffer in memory always >>> | pipeline - directly pass the read data to the backend) >> >> This will definitely be resolved ;) >> > Pipeline is a little complex. FastCGI process would write during reading. so > mod_fcgid should check both read and write on the socket, and read/write while > the socket is readable/writeable. > But is do-able :) Any one interesting?
I'm interested, but need to find adequate time. (I can certainly find time to review and help test somebody else's implementation.) > >>> >>> 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).
