Hi,
Please check the latest cvs tree for new source code. The new release has
fix this problem.
Now mod_fcgid will swap the http request to disk if it's longer than 64k :)
And I added two configurations:
MaxRequestLen( default 1G byte, return internal server error if http
request longer than it)
MaxRequestInMem( default 64k, store the request to tmp file if request
longer than it)
Thanks
----- Original Message -----
From: "Gabriel Barazer" <[EMAIL PROTECTED]>
To: <mod-fcgid-users@lists.sourceforge.net>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, April 30, 2007 9:21 PM
Subject: fcgid large file uploading and input buffering
> Hello,
>
> I experienced recently some problmes since a customer is doing large
> file uploads with PHP (which is run by mod_fcgid, of course) : It seems
> mod_fcgid is consuming much memory when uploading a file to PHP. I found
> in the source file fcgid_bridge.c:473 the problem : as said in the
> source, the entire request (stdin/post input) is loaded into memory
> before sending it to the fastcgi Application Server (PHP in our case).
> Although it's a well workaround for dealing with slow clients, I think
> this is not the good behavior to implement, here are the points
> highlighted :
> - Uploading files is becoming a major security problem, since a DoS can
> be triggered by uploading a very large file (I experienced some attacks
> with 1/2GB over a fast connection)
> - Additionnally, Video (=large) file uploading is becoming more and more
> popular, increasing the memory consumption.
> - Dealing with slow clients must be done by the appliction server, which
> can take any appropriate measure (e.g. having a special queue processing
> for slow clients)
> - Upload progress meter is not possible if all the input data is
> buffered before sent to the fastcgi process. (see RFC1867 : File Upload
> Progress hook handler)
> - Upload of large files is better handled by the fast cgi AS, because of
> various method used to store the upload data during progress (at the
> application level , not the communication level that fastcgi is). e.g.
> PHP handles file upload by creating temporary files, which location of
> these can be customised by a php.ini directive. I think this task has
> not to be handled by the fastcgi layer (which serves as a comm./bridge
> protocol, not a input processor)
> - There is no need for the fastcgi process manager to handle and buffer
> slow clients : A FastCGI application designed to handle load can handle
> multiple connections AND the mod_fcgid process manager already does
> multiple connection management with the adaptive spawning feature for
> application which are not multi-tasked/threaded. (I even know fastcgi
> applications which embed a process manager themselves)
>
>
> What are the problems with slow clients :
> - Sending input is very long, not constant : e.g. with shaped
> connections : data flow is sent by "peaks" foloowed by no data input for
> a variable time.
> - Connection is longer busy at the Apache level, but at the fastcgi
> application level too (the workaround of buffering all the input prevent
> the fastcgi app from being busy buring the input loading).
>
> How to deal with this, my proposal :
> - What about buffering input like the output buffer, by chunks of, say,
> 8Kbytes ? The major problem is the time to fill the buffer : if the time
> required to fill the buffer is too long, application can timeout, but I
> think this is the normal behavior of an application to manage
> communication timeout. What about don't buffering the input at all ?
> This way the data flow AND the data flow rate can by processed by the
> application (such as measuring the data flow rate to put a slow request
> in a special queue).
> - Because maybe some users prefer the current behavior of buffering all
> the input data, a compatibility switch would be a nice thing (e.g.
> InputBuffering Off / On)
>
> What do you think about it ?
>
> BTW: who are the current maintainer(s) of this project ? The
> documentation of this project is not very up-to-date and I had to read
> the source code to know all the directives... Maybe can I be of some help ?
>
> Regards,
>
> Gabriel
>
>
> -------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Mod-fcgid-users mailing list
Mod-fcgid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mod-fcgid-users
