Edit report at https://bugs.php.net/bug.php?id=64187&edit=1
ID: 64187
Updated by: php-bugs@lists.php.net
Reported by: nachms+php at gmail dot com
Summary: CGI/FastCGI truncates input to modulo 4GB
-Status: Feedback
+Status: No Feedback
Type: Bug
Package: Streams related
Operating System: Linux
PHP Version: 5.6
Assigned To: mike
Private report: N
New Comment:
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
Previous Comments:
------------------------------------------------------------------------
[2014-07-28 18:15:27] mike@php.net
Anything to add?
------------------------------------------------------------------------
[2014-07-17 13:18:22] mike@php.net
Sorry for the confusion. INI(enable_post_data_reading) only affects POSTs not PUTs. Anything
non-POST is *not* automatically read into the temp stream.
------------------------------------------------------------------------
[2014-07-17 11:19:13] nachms+php at gmail dot com
> Yes, the php://input stream is creating a temporary file in INI(upload_tmp_dir).
This cannot be disabled ATM.
Based on some superficial testing, it appears that only POST is obeying that variable, but not PUT,
but we'll do more testing to be certain.
It may also make sense to have two separate variables to control PUT and POST.
> If you set INI(enable_post_data_reading) to "Off", it will defer creation until you
> actually read it, i.e. it will write to the temp file as you read from the stream.
We need to do more testing here too, but after talking to our security team about this change to
PHP, they seem to think there's a good chance PHP 5.6 can be DoS'd by PUTing a huge amount
of data to any script, at least when automatic file creation is enabled.
Hopefully, we'll have more testing done later today.
------------------------------------------------------------------------
[2014-07-17 06:26:00] mike@php.net
Thank you for testing!
Yes, the php://input stream is creating a temporary file in INI(upload_tmp_dir).
This cannot be disabled ATM.
If you set INI(enable_post_data_reading) to "Off", it will defer creation until you
actually read it, i.e. it will write to the temp file as you read from the stream.
If INI(enable_post_data_reading) is "Off" and php://input is not used, the input data will
be discarded at the end of the request.
------------------------------------------------------------------------
[2014-07-16 21:20:05] nachms+php at gmail dot com
I played more with 5.6, finding it odd that we're being limited to ~1.7GB (which seems to have
no mathematical significance), whereas in PHP 5.3-5.5, we were seeing the size upload capped to
Content-Length%4GB.
Then I noticed that's how much free space is available in /tmp on our test server.
In PHP < 5.6, uploads via PUT were streamed, so the PHP script could save wherever it wanted to
as it was being uploaded, or stream the data into a database or remote server, or just run some
formulas on the data without storing any of raw PUT data.
In PHP 5.6, it seems the truncation bug has been corrected, but in the process the data is no longer
streamable, making it difficult to effectively deal with huge files, introducing issues into past
cases that worked (because they were <4GB).
Is there a way to tell PHP 5.6 to not buffer/save uploads via PUT? PUT, unlike POST doesn't
need PHP to parse the data to put into the various superglobals.
------------------------------------------------------------------------
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