On Wed, 08 Dec 2010 19:13:08 -0000, Clint Byrum <cl...@ubuntu.com> wrote:
On Wed, 2010-12-08 at 18:49 +0000, Gustavo Lopes wrote:
On Wed, 08 Dec 2010 15:10:30 -0000, Clint Byrum <cl...@ubuntu.com>
wrote:
This example would be solved if during the lazy load you change the
php://input stream to point at the memory location that you read it
into.
I'm sorry, this doesn't make any sense. "The memory location you read
into"? Who says you read the post data *into* something, much less a
memory location?
Sorry, to be more clear:
A lazy load on access to $_POST or $HTTP_RAW_POST_DATA would have to
read the POST data from the SAPI. At that point, the SAPI can keep the
buffer it allocates to read that data as a memory stream, and change its
notion of php://input to refer to that stream.
What would be possible would be to consume all the data from a SAPI
(typically indirectly from a socket, e.g. an Apache brigade), store it
memory and make php://input read from there (i.e., the current behavior)
but in a lazy manner when $_POST and $HTTP_RAW_POST_DATA are read.
However, this wouldn't solve the problem this option tries to resolve,
i.e., avoid consuming the POST data into memory when all that's needed is
a a stream-like access to that data (it also solves the problem the raw
POST data is not available in multipart requests).
It wouldn't be solved because you would have to copy all the data into
memory to permit multiple reads from php://input (the example I gave) and
to allow reading from $_POST and php://input in the same request (for
example, if you access $_POST first, you have to consume the whole POST
data to build the array; at this point you will have needed to store this
data somewhere to make it available to a subsequent read from php://input).
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
