Edit report at https://bugs.php.net/bug.php?id=64187&edit=1
ID: 64187
User updated by: nachms+php at gmail dot com
Reported by: nachms+php at gmail dot com
Summary: CGI/FastCGI truncates input to modulo 4GB
-Status: Feedback
+Status: Open
Type: Bug
Package: Streams related
Operating System: Linux
PHP Version: 5.4.11
Block user comment: N
Private report: N
New Comment:
I just tested with 5.5.12, getting the same results as I did with 5.3.x and 5.4.x, so yes, the bug
has not been fixed.
I noticed my pastes with test code expired. So I quickly whipped up some more:
HTTP: http://paste.nachsoftware.com/Nach/LnpHS6e57f952e3f56df4fcc753c210e8401a7vM
CGI: http://paste.nachsoftware.com/Nach/vCDhzd84835a1b4439c96ad0353c2111051a09zj
Previous Comments:
------------------------------------------------------------------------
[2014-07-13 01:08:36] yohgaki@php.net
PHP 5.5 and up should be able to handle large input. Do you still have this issue?
------------------------------------------------------------------------
[2013-02-20 03:47:08] nachms+php at gmail dot com
Hi payden,
Thanks for the info and your test script. I'll try to run some tests myself when I get a
chance. No worries about hardcoded data, you'll see the C files I provided hardcode data as
well.
Regarding the comment breaking, did you test to ensure things are not broken with the original
un-commented PHP code?
Also, the PHP I provided actually contains a typo, fclose($tfp); should be fclose($ifp);
Perhaps this is why things are being left open?
As for the 4GB limitation, indeed 99% of users would not care. However I created a file-sharing
website using PHP, and ran into this ridiculous limitation. For the time being, I'm using a
slight variation on my patch here on my Apache+FastCGI+PHP5-CGI site. I have yet to play with the
PHP5-FPM SAPI though, but hope to thanks to your script.
------------------------------------------------------------------------
[2013-02-20 03:44:06] payden at paydensutherland dot com
Also, I didn't mention, my program hangs waiting for FPM to close the connection
with the count_bytes line commented out. With the count_bytes line, this is my
output:
FCGI_STDOUT:
======
X-Powered-By: PHP/5.4.11
Content-type: text/html
Array
(
[USER] => www-data
[HOME] => /var/www
[FCGI_ROLE] => RESPONDER
[QUERY_STRING] => test
[REQUEST_METHOD] => PUT
[CONTENT_TYPE] =>
[CONTENT_LENGTH] => 4296015872
[SCRIPT_NAME] => /index.php
[REQUEST_URI] => /
[DOCUMENT_URI] => /index.php
[DOCUMENT_ROOT] => /home/payden
[SERVER_PROTOCOL] => HTTP/1.1
[GATEWAY_INTERFACE] => CGI/1.1
[SCRIPT_FILENAME] => /home/payden/index.php
[SERVER_NAME] => test.localhost.net
[HTTP_HOST] => test.localhost.net
[REMOTE_ADDR] => 127.0.0.1
[REMOTE_PORT] => 12312
[SERVER_ADDR] => 127.0.0.1
[SERVER_PORT] => 80
[PHP_SELF] => /index.php
[REQUEST_TIME_FLOAT] => 1361331663.522
[REQUEST_TIME] => 1361331663
[argv] => Array
(
[0] => test
)
[argc] => 1
)
Amount Read: 2147483647
======
FCGI_END_REQUEST
Connection closed.
Actually sent: 2155288000
So, it finishes cleanly with stock 5.4.11, but the number of bytes actually sent
before FPM closes the connection varies and the PHP side of things always
reports max 32-bit signed int as amount read.
------------------------------------------------------------------------
[2013-02-20 03:31:20] payden at paydensutherland dot com
Hey nachms,
I played around a bit more and it seems that the count_bytes comment does in
fact break things in FPM. I don't know why I didn't notice it the other day.
It seems that FPM doesn't clean things up properly or terminate the connection
even though it does recv all the bytes sent across the wire. It behaves fine
during the send and will output to FCGI_STDOUT records while it's still reading
FCGI_STDIN and I had the PHP script report the amount of bytes read after each
call to fread(). It does in fact read all the bytes, but as I said, FPM does
not close the connection after it sends FCGI_END_REQUEST. I also notice that it
left some junk in the reserved bytes of the FCGI_END_REQUEST body which is
definitely broken behavior. Anywho, I might see if I can come up with a fix
sometime. I'm sure it's not high priority for the PHP folks. It's not often
one sends 4GB+ of data over FastCGI to PHP. Now, no judging me on this because
it is definitely hacky and thrown together and buggy, but I'll throw the C I've
been using to test this up on my server. http://paydensutherland.com/php-
64187.c. Maybe you can do something useful with it. The FCGI_PARAMS are hard
coded, so you'll need to point the DOCUMENT_ROOT and SCRIPT_FILENAME and such to
actual paths on your system. Cheers.
------------------------------------------------------------------------
[2013-02-19 05:34:17] nachms+php at gmail dot com
payden, thanks for the info. It's nice to know that the fix works properly with FPM builds as
well, and even on 32-bit!
I wouldn't mind testing that out myself. Can you post your C FCGI client? Thanks.
Allowing others to easily test and report if they can reproduce the problem or not in other cases
may help the PHP developers too (or not, no idea how important the votes and statistics are).
------------------------------------------------------------------------
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
https://bugs.php.net/bug.php?id=64187
--
Edit this bug report at https://bugs.php.net/bug.php?id=64187&edit=1