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: Open Type: Bug Package: Streams related Operating System: Linux PHP Version: 5.4.11 Block user comment: N Private report: N New Comment: 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). Previous Comments: ------------------------------------------------------------------------ [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. :) ------------------------------------------------------------------------ [2013-02-19 02:27:04] payden at paydensutherland dot com I may be way off here, but from what I can see in SAPI.c (for 5.4.11, line 266 is where the callback is invoked), count_bytes is the number of bytes that the sapi_module_struct->read_post callback can safely stuff in the buffer without overflowing its bounds. I think ignoring count_bytes in the callback is probably a bad idea. Just my two cents. I'll be looking more into it and I'll post here if I come up with a solution. ------------------------------------------------------------------------ [2013-02-11 19:27:39] nachms+php at gmail dot com Due to lack of comments as mentioned above, I'm unsure what the problematic loop is needed for. However thinking more about it, perhaps it's needed for pipelining or multiplexing? In which case, changing read_post_bytes in SAPI.h from int to long, and removing the uint cast from SG(request_info).content_length may be the correct solution. ------------------------------------------------------------------------ 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