On Tue, 07 Dec 2010 12:01:59 -0000, Derick Rethans <der...@php.net> wrote:
On Tue, 7 Dec 2010, Gustavo Lopes wrote:
The very simple attached patch adds an option to disable POST data
processing, which implies the data can only be read in
a stream fashion through php://input.
Does without this patch, reading POST data from php://input work?
Maybe.
In case of a multipart/form-data request, it won't.
For other requests, it will. However, php://input will be reading from
memory, not from the SAPI, because the entire POST data will be in memory.
The new option makes the behavior for a POST request similar to that of
e.g. a PUT request, i.e., data can only be read with php://input and it
will *not* be copied entirely into memory before the user code executes.
Of course the user can use something like file_get_contents('php://input')
to do that, but, depending on the application, he may take advantage of
the low memory usage a stream provides (for the XML payload example, he
could use a SAX-like parser, for proxying or saving the entire request
into disk -- possibly filtered -- he could use stream_copy_to_stream,
etc.).
This introduces a new ini setting, disable_post_data_processing, but
it's a benign one. No incompatibilities between setups will arise
because no one will enable it globally (it would be insane),
Because they can, people will do it though... I'm not fan of more ini
settings.
I'm sure someone somewhere will enable it eventually without being aware
of what it does (despite the obvious name...); my point is that
programmers don't need to program against it (unlike say, magic quotes)
because no working PHP setup will have it enabled, as it breaks every
script that handles POST data.
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
