#38757 [Opn->Fbk]: MultiPart Form Uploads fail with FastCGI

ID: 38757 Updated by: dmitry@php.net Reported By: davidb at pins dot net -Status: Open +Status: Feedback Bug Type: Apache related Operating System: Solaris 8 PHP Version: 5.1.6 Assigned To: dmitry New Comment: The bug should be fixed in CVS HEAD and PHP_5_2. Please verify and close or reopen bug. I just incrised the data waiting timeout from 1 to 5 sec. It is good idea to use SO_ACCEPTFILTER instead of timeout, but it is avbailable only on BSD. Previous Comments: ------------------------------------------------------------------------ [2006-09-12 16:03:41] davidb at pins dot net A few other quick comments: - Perl + CGI::Fast hasn't reported any of these problems - This is only affecting a small subset of users, but those users tend to continue to have the problems recur - The users with recurring problems will sometimes suddenly, and without warning, start working again I strongly suspect some odd network interaction, but I'm not entirely sure where to dig deeper just yet. The FastCGI PHP instance is linked as a local UNIX socket: FastCgiServer /export/httpd/DOMAINS/host.forward.com/cgi-bin/php -port 9050 AddHandler php-fastcgi .php <Location /cgi-bin/php> SetHandler fastcgi-script </Location> Action php-fastcgi /cgi-bin/php There are several other vhosts that use teh FastCgiExternalServer directive. We are using the PHP process manager to front-end the PHP work threads by setting PHP_FCGI_CHILDREN. ------------------------------------------------------------------------ [2006-09-12 15:50:36] davidb at pins dot net Greetings. Is the poll() timing out, even though it appeared to get all of the data in fd4? Or, is there additional data that isn't getting passed on for some reason? I can send the entire truss if you'd like. We're running Apache 1.3.33, Solaris 8, on a dual-processor SPARC. I believe it's the 2.4.2 FastCGI. I do note that the read() that a valid post gets is different. In a good truss: poll(0xFFBED8F0, 1, 1000) = 1 read(4, "0101\001\0\b\0\0", 8) = 8 read(4, "\001\0\0\0\0\0\0", 8) = 8 read(4, "0104\001\015\0\0", 8) = 8 read(4, 0xFFBDD918, 21) = 21 0E05 C O N T E N T _ L E N G T H 6 1 0 1 5 read(4, "0104\001\0 V\0\0", 8) = 8 read(4, 0xFFBDD918, 86) = 86 \f H C O N T E N T _ T Y P E m u l t i p a r t / f o r m - d a t a ; b o u n d a r y = - - - - - - - - - - - - - - - - - - - - - - - - - - - 1 9 1 9 4 1 1 2 6 6 2 0 5 9 7 read(4, "0104\001\0 =\0\0", 8) = 8 read(4, 0xFFBDD918, 61) = 61 \r . D O C U M E N T _ R O O T / e x p o r t / h t t p d / D O M A I N S / t e s t 2 . f o r w a r d . c o m / h t d o c s The poll seems to return with a 1, but the data that's read in is the same. Is there something about the submit from different users that would cause the poll() to return differently? I have network snoops, as well. ------------------------------------------------------------------------ [2006-09-11 07:55:00] dmitry@php.net From the strace log I see: PHP FastCGI server accepts connection and waits 1 sec (in pool()) for any input from HTTP client. It doesn't get any data in a second and does save connection close. Could you describe your environment: CPU speed, WebServer, fastcgi plugin, fastcgi configuraion... ------------------------------------------------------------------------ [2006-09-09 21:09:16] tony2001@php.net Dmitry, could you plz check it out? ------------------------------------------------------------------------ [2006-09-09 02:05:01] davidb at pins dot net Well, I tried with the latest 5.2b snapshot, and now it's broken for my PC at home also. Appears to be the identical problem - php just silently stops processing after it reads in the POST data, closes the socket, and then waits for the next request, throwing a 500 server error. Please. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/38757 -- Edit this bug report at http://bugs.php.net/?id=38757&edit=1