Req #55815 [Com]: PUT request data should be parsed just like POST
Edit report at https://bugs.php.net/bug.php?id=55815&edit=1
ID: 55815
Comment by: phazei at gmail dot com
Reported by:catch dot dave at gmail dot com
Summary:PUT request data should be parsed just like POST
Status: Open
Type: Feature/Change Request
Package:Streams related
Operating System: All
PHP Version:5.4.0beta1
Block user comment: N
Private report: N
New Comment:
Has this been reconsidered at all? Any update?
Previous Comments:
[2012-04-16 19:15:43] catch dot dave at gmail dot com
Hi theanomaly,
I'd like to address your points.
1. As per my original request the manual page of
"http://php.net/manual/en/features.file-upload.put-
method.php" *does not* solve the problem, as it does not handle multipart form
requests.
2. Implementing the parsing of multipart form data in PHP seems to be re-
inventing the wheel when the
code to correctly parse this already exists in PHP itself (to parse POST data).
3. Perhaps I am misunderstanding, but reading through both your quote and the
rest of the 2616 spec, I
fail to see how the spec precludes handling form-data in a PUT method, The
section you quoted is saying
that:
* PUT must operate on the URI provided and not another one; and
* that the difference between PUT and POST, is that POST URI defines the
resource that operates on
an entity, whereas a PUT request's URI identifies the entity itself. It is
common to use the PUT verb to
operate on existing entities in restful APIs (e.g. modifying the title of an
existing book, you would send
the new title as data, and not in the URI itself), which does not seem to
violate this point either.
The multipart form data is part of the original user request and should
therefore be parseable--the user
is sending the data (in multipart form) to operate on the URI using the PUT
method.
I don't think the spec is saying that you are not allowed to use/consider the
data sent along with it--
as opposed to your interpretation which suggests the RFC is saying that all
data
other than the URI
itself (whether multipart form encoded or not) should be ignored.
4. I had originally had some code that does exactly what you described, but it
was nowhere near as
robust as the existing code in PHP, which lead to me writing this request (re-
invent the wheel).
Furthermore, other languages (e.g. Ruby) do parse multipart data in PUT (not
that that should be the
primary reason).
[2012-04-11 01:52:33] theanomaly dot is at gmail dot com
First, I'd like to start by noting that the PHP manual already addresses file
uploads via PUT method by:
http://php.net/manual/en/features.file-upload.put-method.php
Second, I want to point out that what you're asking is actually a violation of
the HTTP specification as per RFC 2616 specifically Section 9.6
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6
"The fundamental difference between the POST and PUT requests is reflected in
the different meaning of the Request-URI. The URI in a POST request identifies
the resource that will handle the enclosed entity. That resource might be a
data-accepting process, a gateway to some other protocol, or a separate entity
that accepts annotations. In contrast, the URI in a PUT request identifies the
entity enclosed with the request -- the user agent knows what URI is intended
and the server MUST NOT attempt to apply the request to some other resource. If
the server desires that the request be applied to a different URI, it MUST send
a 301 (Moved Permanently) response; the user agent MAY then make its own
decision regarding whether or not to redirect the request."
What this means is the HTTP RFC does not allow us to identify multipart/form-
data in a PUT request.
Thus your proposed implementation to how PHP already handles requests would
then
put PHP in a position of having not complied with the spec. PUT is used for a
different specification than POST and thus modifying PHP to treat them equally
would not be a sane solution.
However, there are some simple steps to accomplishing what you want even though
it would be in violation of the HTTP specification. Namely they would be:
1) You can detect whether or not PUT was the REQUEST method via
$_SERVER['REQUEST_METHOD'] for example (depends on your SAPI).
2) You may then proceed to process the 'php://input' stream through something
like file_get_contents('php://input'); - as an example.
3) You may then proceed to break up the multipart form data according to its
defined boundaries in PHP user-space code -- according to the specification at
http://tools.ietf.org/html/rfc2388
4) Finally you may chose to do with the file
[PHP-BUG] Bug #54189 [NEW]: foreach changes array values after iterating by reference followed by foreach
From:
Operating system: RHEL 5.6
PHP version: 5.2.17
Package: Scripting Engine problem
Bug Type: Bug
Bug description:foreach changes array values after iterating by reference
followed by foreach
Description:
(I searched through the bug reports and found some foreach pointer issues,
but
none related to this)
If I simply go through an array with a referenced value like so:
foreach ($array as &$value) { }
And then go through it again, not referenced, like so:
foreach ($array as $value) { }
Both times using the same variable $value, then during the second foreach,
the
second to the last value is actually copied over the last value changing
the
array.
If I simply use $value2 there is no issue.
Test script:
---
$array = array('a','b','c','d','e');
echo '1) '.print_r($array, true).'';
foreach ($array as &$value) { }
echo '2) '.print_r($array, true).' 3) ';
foreach ($array as $key => $value) { echo "[$key] => $value "; }
echo ' 4) '.print_r($array, true).'';
Expected result:
1) Array ( [0] => a [1] => b [2] => c [3] => d [4] => e
)
2) Array ( [0] => a [1] => b [2] => c [3] => d [4] => e
)
3) [0] => a [1] => b [2] => c [3] => d [4] => e
4) Array ( [0] => a [1] => b [2] => c [3] => d [4] => e
)
Actual result:
--
1) Array ( [0] => a [1] => b [2] => c [3] => d [4] => e
)
2) Array ( [0] => a [1] => b [2] => c [3] => d [4] => e
)
3) [0] => a [1] => b [2] => c [3] => d [4] => d
4) Array ( [0] => a [1] => b [2] => c [3] => d [4] => d
)
--
Edit bug report at http://bugs.php.net/bug.php?id=54189&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54189&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54189&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54189&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54189&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54189&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54189&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54189&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54189&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54189&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54189&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54189&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54189&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54189&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54189&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54189&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54189&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54189&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54189&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54189&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54189&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54189&r=mysqlcfg
Bug #50749 [Com]: max_file_uploads counts empty uploads as well
Edit report at http://bugs.php.net/bug.php?id=50749&edit=1 ID: 50749 Comment by: phazei at gmail dot com Reported by:anzenews at volja dot net Summary:max_file_uploads counts empty uploads as well Status: Bogus Type: Bug Package:PHP options/info functions Operating System: Linux PHP Version:5.2.12 Block user comment: N New Comment: This is actually very similar to this bug: http://bugs.php.net/bug.php?id=50692 That was filed a few days earlier. Does it take significantly more resources than if someone simply tried to flood the server with a load of input type=text? Not being able to set this with ini_set (http://bugs.php.net/bug.php?id=50684 ) is a big issue as well that makes this an all or none problem rather than setting an exception for an admin page or something similar. Previous Comments: [2010-01-15 16:03:27] ras...@php.net The server does actually need resources even for an empty upload because we don't necessarily know it is empty until late in the request. We have to create the filename and sit and wait for the data, even if none ever comes. So, from a server resource perspective there is very little difference between an empty upload and a non-empty one. [2010-01-15 10:15:59] anzenews at volja dot net Then this function is no better than the safe mode, magic quotes and similar fiascos of PHP - useless and will be avoided, at least by me. The purpose of this function is to protect the server from DOS attacks. Does the server need many resources to process the empty files? I would guess not. On the other hand this is very limiting for forms that wish to have many _optional_ file upload input fields (which was how I stumbled across this bug). Anyway, I'll just be careful to choose a host with this "feature" turned off in the future, the same as I did with safe mode. :( Oh, and by the way, turning it on by default in the very first incarnation of this option is not very nice IMHO. It took me quite some time to figure out what is going on since there are almost no pages with this setting described yet. :( [2010-01-15 08:55:11] j...@php.net Of course it does, that's exactly it's purpose: to limit maximum number of uploads. And yes, even "empty" upload is an upload. [2010-01-14 13:46:53] anzenews at volja dot net Description: Setting max_file_uploads limits the number of file input fields on HTML page instead of limiting the number of actually uploaded files. Reproduce code: --- \n". ''."\n"; }; ?> Expected result: When you upload a single file (in the LAST!!! input box) and hit "OK!", you should see the uploaded file. Actual result: -- Instead you see just 20 empty file uploads. (if max_file_uploads is set to 20, as per default) The max_file_uploads setting should never count empty files. -- Edit this bug report at http://bugs.php.net/bug.php?id=50749&edit=1
Req #50692 [Com]: Don't count 0-bytes files towards the max_file_uploads limit
Edit report at http://bugs.php.net/bug.php?id=50692&edit=1 ID: 50692 Comment by: phazei at gmail dot com Reported by:john dot peterson10 at gmail dot com Summary:Don't count 0-bytes files towards the max_file_uploads limit Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: Windows PHP Version:5.2.12 Block user comment: N New Comment: This is an issue for me as well. It can't be adjusted with ini_set or in .htaccess : http://bugs.php.net/bug.php?id=50684 Previous Comments: [2010-03-12 14:40:20] mariusads at helpedia dot com Those people with websites showing 40 input boxes could just as easy increase the value of the limit in the php.ini or pass it on a case by case basic through .htaccess (if possible, i don't know) Don't see the point of this... [2010-01-08 07:42:43] john dot peterson10 at gmail dot com Description: Suggestion: Don't count 0-bytes files (that comes from elements that don't have any file specified) towards the max_file_uploads limit. (And don't create a blank temporary file for them to avoid the problems with file-system overload mentioned in CVE-2009-4017.) Reason for suggestion: That way a small limit for max_file_uploads will cause less website restrictions. For example: I have seen some designs with lists of 40 or 50 rows where every row has a for the sake of the design of the page. But where typically only one or two files are submitted in a POST because the majority of the elements has no file specified. Currently all these designs will be limited (to for example 20 rows with the default settings) because even 0-byte files count towards the max_file_uploads limit. Issues with suggestion: The site will need javascript to control the rare exception where more than for example 20 has a value before submit. But that should not be a big problem. Reproduce code: --- HTML POST request with elements where the value is blank (no file specified) so that $_FILES[#]['size'] is 0 (and $_FILES[#]['tmp_name'] is blank). Expected result: elements where no file is specified doesn't count towards the max_file_uploads limit Actual result: -- elements where no file is specified counts towards the max_file_uploads limit -- Edit this bug report at http://bugs.php.net/bug.php?id=50692&edit=1
