PHP input stream php: // input

When using xml-rpc, the server obtains client data mainly through the php input stream input instead of the $ _ POST array. Therefore, we will mainly discuss the introduction of php input stream php: input to php: input. The official PHP Manual provides a clear overview of php input stream. Php: inputallowsyoutoreadrawPOSTda

When using xml-rpc, the server obtains client data mainly through the php input stream input instead of the $ _ POST array. So here we will mainly discuss the introduction of php input stream php: // input to a php: // input. The official PHP Manual provides a clear overview of it. Php: // input allows you to read raw POST da

When using xml-rpc, the server obtains client data mainly through the php input stream input instead of the $ _ POST array. So here we will mainly discuss php input stream php: // input

For a php: // input introduction, the PHP official manual provides a clear overview of it.

"Php: // inputAllows you to read raw POST data. It is a less memory intensive alternative$ HTTP_RAW_POST_DATAAnd does not need any specialPhp. iniDirectives.Php: // inputIs not availableEnctype = "multipart/form-data".
The translation is like this:
"Php: // input can read POST data that has not been processed. Compared with $ HTTP_RAW_POST_DATA, it puts less pressure on memory and does not require special php. ini settings. Php: // input cannot be used for enctype = multipart/form-data"

How should we understand this overview ?! I divided it into three parts and gradually understood it.

1. Read POST Data
2. Cannot be used for multipart/form-data Type
3. Php: // input VS $ HTTP_RAW_POST_DATA

Read POST Data

PHPer must be familiar with the built-in variable $ _ POST. $ _ What are the associations and differences between POST and php: // input? In addition, the most common method for the client to interact with the server is POST and GET. Since php: // input is used as the PHP input stream, can it read GET data? These two questions are what we need to discuss in this section.
Experience tells us that summing up from testing and observation will be a very useful method. Here, I wrote a few scripts to help us test.

@ File 192.168.0.6:/phpinput_server.php print the received data @ file 192.168.0.8:/phpinput_post.php simulate the POST method to submit form data @ file 192.168.0.8:/phpinput_xmlrpc.php simulate the POST method to issue the xmlrpc request. @ file 192.168.0.8:/phpinput_get.php simulate the number of tables submitted using the GET Method

Phpinput_server.php and phpinput_post.php

We can use ngrep to capture http Request packets (because we need to know php: // input, we only capture http Request packets here ). Run the test script phpinput_post.php.

@php /phpinput_post.php

HTTP/1.1 200 OKDate: Thu, 08 Apr 2010 03:23:36 GMTServer: Apache/2.2.3 (CentOS)X-Powered-By: PHP/5.1.6Content-Length: 160Connection: closeContent-Type: text/html; charset=UTF-8-------$_POST------------------array(2) {  ["n"]=> string(9) "perfgeeks"  ["p"]=> string(4) "7788"}-------php://input-------------n=perfgeeks&p=7788

The http Request Packet captured through ngrep is as follows:

T 192.168.0.8:57846 -> 192.168.0.6:80 [AP]  POST /phpinput_server.php HTTP/1.1..  Host: 192.168.0.6..Content-Type: application/x-www-form-urlencoded..Co  ntent-Length: 18..Connection: close....n=perfgeeks&p=7788....

It is not difficult to find out after careful observation
1, $ _ POST data, php: // the input data is "consistent" with the httpd entity body data
2. the Content-Type in the http request is application/x-www-form-urlencoded, which indicates that the data in the http Request body is the form data submitted using the http post method, and urlencode () is processed.
(Note: note that the content in the bold part will not be prompted below ).

Let's take a look at the original file content of the script phpinput_xmlrpc.php, which simulates an xml-rpc Request Submitted by the POST method.

Similarly, let's execute this test script.

@php /phpinput_xmlrcp.php

HTTP/1.1 200 OKDate: Thu, 08 Apr 2010 03:47:18 GMTServer: Apache/2.2.3 (CentOS)X-Powered-By: PHP/5.1.6Content-Length: 154Connection: closeContent-Type: text/html; charset=UTF-8-------$_POST------------------array(0) {}-------php://input-------------
  
     
   
    jt_userinfo
   
  

When executing this script, the http request packet captured through ngrep is as follows:

T 192.168.0.8:45570 -> 192.168.0.6:80 [AP]  POST /phpinput_server.php HTTP/1.1..  Host: 192.168.0.6..Content-Type: text/html..Content-Length: 75..Connec  tion: close....
  .
  
   .   
   
    jt_userinfo<  /name>.
   
  ....

Similarly, I can easily find that:
1. the Content-Type in the http request is text/xml. It indicates that the body data in the http request is in xml format.
2. The server $ _ POST prints an empty array, which is inconsistent with the http entity body. This is different from the previous example. The Content-Type here is text/xml, not application/x-www-form-urlencoded.
3. php: // the input data is consistent with the http entity body data. That is, php: // the input data is inconsistent with the $ _ POST data.

Let's take a look at the situation where the form data is submitted using the GET method. Can php: // input read the form data of the GET method? Here, we will slightly change the phpinput_server.php file and change $ _ POST to $ _ GET.

Similarly, we run the next phpinput_get.php test script, which simulates a common GET method to submit form data.

@php /phpinput_get.php

HTTP/1.1 200 OKDate: Thu, 08 Apr 2010 07:38:15 GMTServer: Apache/2.2.3 (CentOS)X-Powered-By: PHP/5.1.6Content-Length: 141Connection: closeContent-Type: text/html; charset=UTF-8-------$_GET------------------array(2) {  ["n"]=>  string(9) "perfgeeks"  ["p"]=>  string(4) "7788"}-------php://input-------------

At this time, the ngrep tool is used to capture the corresponding http request packet as follows:

T 192.168.0.8:36775 -> 192.168.0.6:80 [AP]  GET /phpinput_server.php?n=perfgeeks&p=7788 HTTP/1.1..  Host: 192.168.0.6..Connection: close....

Compare the http requests submitted by the POST method. Generally, the entity body is empty in the requests submitted by the GET method. Content-Type and Content-Length are not specified. However, if the strong data is http entity body and the Content-Type and Content-Length are specified correctly, php: // input still reads the http entity body data, but not $ _ GET data.

Based on the above probes, We can summarize the following:
1. When the value of Content-Type is application/x-www-form-urlencoded, php will fill in the corresponding data of the http Request body to the array $ _ POST, the data filled in the $ _ POST array is the result of urldecode () parsing. (In fact, in addition to the Content-Type, there is also multipart/form-data indicating that the data is form data. We will introduce it later)
2, php: // input data, as long as the Content-Type is not multipart/form-data (this condition will be described later ). Php: // the input data is consistent with the part of the http entity body. The consistent data Length is specified by Content-Length.
3. Only when the Content-Type is application/x-www-form-urlencoded and the submission method is POST, $ _ POST data and php: // The input data is "consistent" (with quotation marks, indicating that the formats are inconsistent and the content is consistent. In other cases, they are inconsistent.
4. php: // input cannot read $ _ GET data. The reason is that the $ _ GET data is written in the PATH field of the http Request header as query_path, rather than in the http Request body.

This also helps us understand why the xml_rpc server reads data through file_get_contents ('php: // input', 'R '). Instead of reading from $ _ POST, it is because the xml_rpc data Type is xml, and its Content-Type is text/xml.

Php: // input has encountered multipart/form-data

When uploading files, the form is written in this way.

Enctype = multipart/form-data indicates that the Content-Type in the http Request Header (head) is set to multipart/form-data. Refer to RFC1867's description. Multipart/form-data also means to submit form data using the POST method. It is also accompanied by file upload, so it will be different from the data format of application/x-www-form-urlencoded. It is passed to the server in a more reasonable and efficient data format. We submit the form data and print the response results as follows:

-------$_POST------------------array(1) { ["n"]=> string(9) "perfgeeks" }-------php://input-------------

At the same time, the corresponding http Request Packet captured through ngrep is as follows:

########T 192.168.0.8:3981 -> 192.168.0.6:80 [AP]  POST /phpinput_server.php HTTP/1.1..Host: 192.168.0.6..Connection: kee  p-alive..User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) A  ppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.3 Safari/533.2..Re  ferer: http://192.168.0.6/phpinput_server.php..Content-Length: 306..Ca  che-Control: max-age=0..Origin: http://192.168.0.6..Content-Type: mult  ipart/form-data; boundary=----WebKitFormBoundarybLQwkp4opIEZn1fA..Acce  pt: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q  =0.8,image/png,*/*;q=0.5..Accept-Encoding: gzip,deflate,sdch..Accept-L  anguage: zh-CN,zh;q=0.8..Accept-Charset: GBK,utf-8;q=0.7,*;q=0.3..Cook  ie: SESS3b0e658f87cf58240de13ab43a399df6=lju6o5bg8u04lv1ojugm2ccic6...  .##T 192.168.0.8:3981 -> 192.168.0.6:80 [AP]  ------WebKitFormBoundarybLQwkp4opIEZn1fA..Content-Disposition: form-da  ta; name="n"....perfgeeks..------WebKitFormBoundarybLQwkp4opIEZn1fA..C  ontent-Disposition: form-data; name="f"; filename="test.txt"..Content-  Type: text/plain....i am file..multipart/form-data..------WebKitFormBo  undarybLQwkp4opIEZn1fA--..##

Compare from the response output. The $ _ POST data is consistent with the data submitted by the request, that is, $ _ POST = array ('n' => 'perfgeek '). This also echoes the data in the http Request body. It also indicates that PHP fills in the corresponding data with the $ _ POST global variable. Php: // the input output is empty and nothing is output, although the body of the http request packet is not empty. This indicates that when the Content-Type is multipart/form-data, php: // input is empty even if there is data in the http Request body. In this case, php: // input stream is not entered. Therefore, php: // input cannot be used to read data from enctype = multipart/form-data.

After comparing the http request data packets captured through ngrep, we will find that the biggest difference is that Content-Type follows boundary and defines the data delimiter, bounday is randomly generated. Another big difference is that the data organization structure in the http entity body is different.

In the previous section, we have outlined that when Content-Type is application/x-www-form-urlencoded, php: // input and $ _ POST data are "consistent, when it is other Content-Type, php: // input and $ _ POST data are inconsistent. Because only when the Content-Type is application/x-www-form-urlencoded or multipart/form-data, PHP will fill in the corresponding part of the body of the http request packet in the $ _ POST global variable. PHP will ignore this in other cases. Php: // input is not empty unless the data type is multipart/form-data. Through this section, we understand the difference and connection between php: // input and $ _ POST. So, confirm again that php: // input cannot read enctype = multipart/form-data. When php: // input encounters it, it is always blank, even if the http entity body has data.

Php: // input VS $ http_raw_post_data

I believe you have a deep understanding of php: // input. So what is $ http_raw_post_data? $ Http_raw_post_data is a built-in global variable in PHP. It is used. PHP fills in the POST data as is in the variable $ http_raw_post_data when the Content-Type cannot be recognized. It cannot read POST data whose Content-Type is multipart/form-data. You need to set the always_populate_raw_post_data value in php. ini to On, and PHP will always fill in the POST data with the variable $ http_raw_post_data.

Change the script phpinput_server.php to verify the above content.

Run the test script

@php phpinput_post.php@php phpinput_get.php@php phpinput_xmlrpc.php

The output result is the same, that is, all values are 1, indicating that php: // input and $ HTTP_RAW_POST_DATA are the same. As for the memory pressure, we will not perform a detailed test here. If you are interested, you can use xhprof for testing and observation.

In this section, we can summarize the following:
1. php: // input can read the value of the specified Length in the http entity body, which is determined by Content-Length, whether it is data submitted by POST or GET methods. However, when the GET method submits data, the http request entity body is empty.
2. php: // input and $ HTTP_RAW_POST_DATA read the same data and only read data whose Content-Type is not multipart/form-data.

Study Notes

1. Coentent-Type can only be set to application/x-www-data-urlencoded or multipart/form-data, PHP will fill in the corresponding data in the http request packet with the global variable $ _ POST
2. When PHP cannot recognize the Content-Type, it will fill in the corresponding data in the http request package with the variable $ HTTP_RAW_POST_DATA
3. When the Coentent-Type is not multipart/form-data, PHP will not fill in the corresponding data in the http request packet in php: // input; otherwise, it will be used in other cases. Length Specified by Coentent-Length.
4. php: // input data is consistent with $ _ POST data only when the Content-Type is application/x-www-data-urlencoded.
5. php: // the input data is always the same as $ HTTP_RAW_POST_DATA, but php: // the input data is more efficient than $ HTTP_RAW_POST_DATA, and php. ini does not require special settings.
6. PHP will fill in the query_path section of the PATH field with the global variable $ _ GET. Normally, the http Request Submitted by The GET method has no body.