The PHP documentation states that php://input
can only be read once.
In my application I need to read it twice, once for authentication purposes and once for actually processing the content, and both functions are handled by different, independent modules. The crazy thing is: it works.
Can I count on this working everywhere, or is this a fluke in my version of PHP (5.2.10)? The only documentation I can find about this is the one that states that it shouldn't work, with no version limitation mentioned.
Following Dennis' hunch, I did this test:
$in = fopen('php://input', 'r');
echo fread($in, 1024) . "\n";
fseek($in, 0);
echo fread($in, 1024) . "\n";
fclose($in);
echo file_get_contents('php://input') . "\n";
Curling:
$ curl http://localhost:8888/tests/test.php -d "This is a test"
This is a test
This is a test
Apparently it's limited to one read per open handle.
A little more digging revealed that indeed php://input
can only be read once, ever, for PUT requests. The above example used a POST request.
php://input allows you to read raw POST data. It is a less memory intensive alternative to $HTTP_RAW_POST_DATA and does not need any special php. ini directives. php://stdin and php://input are read-only, whereas php://stdout, php://stderr and php://output are write-only.
The file_get_contents() reads a file into a string. This function is the preferred way to read the contents of a file into a string. It will use memory mapping techniques, if this is supported by the server, to enhance performance.
A little inspection of the source code yields the answers.
First, yes, you're limited to one read per handle because the underlying stream does not implement the seek
handler:
php_stream_ops php_stream_input_ops = {
php_stream_input_write,
/* ... */
"Input",
NULL, /* seek */
/* ... */
};
Second, the read handler has two different behaviors depending on whether the "POST data" has been read and stored in SG(request_info).raw_post_data
.
if (SG(request_info).raw_post_data) {
read_bytes = SG(request_info).raw_post_data_length - *position;
/* ...*/
if (read_bytes) {
memcpy(buf, SG(request_info).raw_post_data + *position, read_bytes);
}
} else if (sapi_module.read_post) {
read_bytes = sapi_module.read_post(buf, count TSRMLS_CC);
/* ... */
} else {
stream->eof = 1;
}
So we have three possibilities here:
SG(request_info).raw_post_data
. In this case, since the data is stored, we can open and read multiple handles for php://input
.php://input
cannot give us anything.php://input
and read it only once.NOTE: What follows is the default behavior. Different SAPIs or additional extensions may change this behavior.
In case of POST requests, PHP defines a different POST reader and a POST handler depending on the content-type.
Case 1. This happens when we have a POST request:
application/x-www-form-encoded
. sapi_activate
detects a POST request with a content-type and calls sapi_read_post_data
. This detects the content-type and defines the POST reader/handler pair. The POST reader is sapi_read_standard_form_data
, which is immediately called and just copies the request body to SG(request_info).post_data
. The default post reader php_default_post_reader
is then called, which fills $HTTP_RAW_POST_DATA
if the ini setting always_populate_post_data
is set and then copies SG(request_info).post_data
to SG(request_info).raw_post_data
and clears the first. The call to the handler doesn't matter here and is deferred until the superglobals are built (which may not happen, in case JIT is activated and the superglobals are not used).php_default_post_reader
without any data read. Since this is a POST request and there's no reader/handler pair, sapi_read_standard_form_data
will be called. This is the same function as the read handler the content type application/x-www-form-encoded
, so all the data gets swallowed to SG(request_info).post_data
. The only differences from now on is that $HTTP_RAW_POST_DATA
is always populated (no matter the value of always_populate_post_data
) and there's no handler for building the superglobals.Case 2. This happens when we have a form request with content-type "multipart/form-data". The POST reader is NULL
, so the handler, which is rfc1867_post_handler
acts as a mixed reader/handler
. No data whatsoever is read in the sapi_activate
phase. The function sapi_handle_post
is eventually called in a later phase, which, in its turn calls the POST handler. rfc1867_post_handler
reads the request data, populates POST
and FILES
, but leaves nothing in SG(request_info).raw_post_data
.
Case 3. This last case takes place with requests different from POST (e.g. PUT). php_default_post_reader
is directly called. Because the request is not a POST request, the data is swallowed by sapi_read_standard_form_data
. Since no data is read, there's not anything left to be done.
Maybe they mean fseek() or rewind() aren't available. Have you tried one of those functions on an opened php://input ?
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With