Edit report at https://bugs.php.net/bug.php?id=64187&edit=1
ID: 64187
Comment by: payden at paydensutherland dot com
Reported by: nachms+php at gmail dot com
Summary: CGI/FastCGI truncates input to modulo 4GB
Status: Open
Type: Bug
Package: Streams related
Operating System: Linux
PHP Version: 5.4.11
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[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).
------------------------------------------------------------------------
[2013-02-19 05:20:31] payden at paydensutherland dot com
Hey,
I did a little testing and have some findings to share. I believe your fix
works perfectly fine with php-fpm and it does not in fact need to be bounded
for
fcgi_read to work correctly. I wanted to duplicate your initial test over fpm
and see what happened. With the the bounding in place, I got some weird
results
with fpm. The PHP script stopped reading and finished executing at exactly
2147483647 bytes. (signed 32-bit int max) When I commented the MIN() out and
rebuilt, the script read the entirety of the 4296015872 bytes I sent it and
reported reading that amount. I used the same PHP code you used for the test
and a hacked together C FCGI client. I am using a 32-bit build of PHP. I
don't
know if any of this information is useful for you, but I was bored and would
kind of like to start watching bugs and getting involved a little bit. Let me
know if I'm going about it the wrong way!
------------------------------------------------------------------------
[2013-02-19 04:32:33] nachms+php at gmail dot com
Problems in PHP are also a bit larger than I described here, although perhaps
should be filed as a separate bug.
32-bit OSs generally have "large file support", and can support handling data
at much larger than 4GB. On most UNIXs, getconf can indicate appropriate flags
to enable such support. On Windows, large file support is always available.
Ideally PHP should ensure such support is available and properly used. For
starters, Content-Length header is stored within a long. It should be stored in
a type guaranteed to be 64 bits, and not depend if the system itself is 32 or
64 bit.
It is okay to limit the amount of data that can be read at once is limited to
32-bit, even on a 64-bit platform. But the overall size on files or input
streams from pipes and sockets should not be.
------------------------------------------------------------------------
[2013-02-19 02:31:22] payden at paydensutherland dot com
Oh, I'm sorry. I must have misread it before. I see you're not ignoring
count_bytes. You're just taking out the MIN() on count_bytes, and remaining
data
to be read. Let me keep my mouth shut until I come up with something
intelligent
to say. :)
------------------------------------------------------------------------
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
