I am searching the exact definition of this, but I still can't find a satisfactory definition.
I was using the NuSOAP web service, and there is a line,
$server->service($HTTP_RAW_POST_DATA);
What is the purpose of $HTTP_RAW_POST_DATA here?
As per my research, it is for collecting raw POST data, but I am not satisfied with the answer. What is the exact meaning of the raw POST data?
An HTTP request consists of two parts. A set of headers and a body.
The headers include things like the URL being requested and caching control helpers (such as "I have a version of this from yesterday, only give me a new one if there are changes, OK?").
The body may or may not appear depending on the type of request. POST requests have bodies.
The body can be in any format the client likes. One of the headers will tell the server what the format is.
There are a couple of formats used by HTML forms, and PHP knows how to parse these and put the data into $_POST.
If the data is in another format, such as JSON, or if the data doesn't conform to PHP's quirks (such as the rules for having [] on the end of keys with the same name) then you might want to access the data directly so you can parse it yourself.That is the raw POST data.
$_POST contains URL encoded (application/www-url-encoded) variables that are posted to your script and PHP decodes them for you. You use this one when you deal with HTML FORM data.
file_get_contents("php://input") - gets the raw POST data and you need to use this when you write APIs and need XML/JSON/... input that cannot be decoded to $_POST by PHP.
$HTTP_RAW_POST_DATA - in theory it is the same as the above but depends on php.ini. and is no longer available in PHP 7
An HTTP message consists of a series of headers and a body (which can be required/optional/forbidden depending on the headers).
For the URL http://stackoverflow.com/questions/43519007/usage-of-http-raw-post-data, the body is the HTML used to generate the document you are reading.
If you make a GET request for it, then there is no request body.
If you make a POST request then there will be. If you submit a form, it will be encoded using one of the formats you can specify with the enctype attribute.
Normally, in PHP, when you want to work with that data, you would use $_POST which contains the content after the body has been decoded.
The raw body is the body before it has been decoded.
The majority of the time, when we're working with HTTP POST requests, we're looking at the result of a form submission from the browser. This will format the data in a standard way (either "query-string encoded" or "multipart/form-data") which encodes a set of key-value pairs. PHP automatically parses any requests in this format into the super-global array $_POST.
However, the actual HTTP request body is just a piece of text, and in some cases we want to treat it as such. For instance, a SOAP request uses an XML document as the body of the POST request. $HTTP_RAW_POST_DATA gives you access to this text - it is "raw" because it hasn't been processed, it's just given back to you as a string.
It's worth noting that the $HTTP_RAW_POST_DATA is an old way of accessing this, and the correct way in newer versions of PHP is to use file_get_contents('php://input'); where php://input is a virtual file which represents that same raw data.
Related
In particular, I am interested in viewing the 3 main types of data routinely sent to PHP, and available in the $_GET, $_POST and $_COOKIE arrays.
I’m not very conversant with HTTP, but as far as I am aware, the data sent from a form (method=post or get), a URL query string, or in cookies, is put into the HTTP headers and then sent to the server. (I’m not entirely sure whether that’s the case for method=post). It is, for the most part, in plain text.
The question is, how can I view this HTTP content in its raw form?
I am interested mainly to get a better understanding of the process.
The only piece of data that ends up in some PHP superglobal that's transmitted in HTTP headers are cookies. Such cookies often include the session ID used by sessions. $_GET gets populated from the URL:
An associative array of variables passed to the current script via the URL parameters
$_POST gets populated from the request body of HTTP request that use POST method, as long as they are formatted using one of the two formats implemented:
An associative array of variables passed to the current script via the HTTP POST method when using application/x-www-form-urlencoded or multipart/form-data as the HTTP Content-Type in the request.
In both cases, you need to understand that they are convenience methods that work when you follow certain guidelines. Not all raw information is usable this way.
As per the way to inspect raw data, all decent major browsers nowadays include developer tools with a Network pane. Such tools are often mapped to the F12 keyboard short-cut. In the PHP side, you can inspect part of the raw URL with var_dump($_SERVER['REQUEST_URI']) (this variable won't include the protocol prefix, host name or port) and you can inspect raw POST body with e.g. var_dump(file_get_contents("php://input")).
You can try $requestBody = file_get_contents('php://input'); I think this can help you.
As all $_GET,$_POST and $_COOKIE are arrays you can aslo do print_r to view the content in raw form.
print_r($_GET);
print_r($_POST);
print_r($_COOKIE);
Okay, so I got a game, that needs to send some stuff from C++ to a PHP page using a post request.
My questions are:
How can I send a post request?
What kind of data can I send over to PHP? (just strings and ints or also entire collections?)
How can I send a post request?
This is normally done using an HTTP library. I've not used one in C++ myself, but cURL is popular across platforms and has [C++ bindings][1] (although the documentation seems to be undergoing migration at the moment).
There is more information on the subject in this question.
What kind of data can I send over to PHP?
Pretty much any data you like - but it has to be a data format rather then a data structure. If you want to send a collection you would need to serialise it to some format. JSON is a popular one. Binary data can be encoded using base64.
If you do use JSON you could either then add a second layer of encoding to send it application/x-www-form-urlencoded and access the raw JSON via $_POST or you can make the JSON the whole body of the POST request and get the body of the post in PHP.
The fact that you say you're sending via POST request tells me that you're using a HTTP server to serve your PHP script. In which case, you want a library that allows you to send HTTP requests. A very popular choice is libcURL. What can you send? You can send anything that a HTTP request would allow you to send. So anything you like.
You can use JSON or SOAP for sending the data. When passing small amount of data JSON is preferred. More info on JSON/SOAP
To build HTTP request consider using libcurl and eventually its c++ wrapper curlpp
You can send whatever you want to php but don't forget that all the data comming from HTTP will be string for php.
PHP can cast to some type like int with intval() or (int) but binary data will be more complex to handle.
Consider using some standars like json and REST to build a robust communication.
My server is sending data to the client.
header('Content-type: application/json');
echo json_encode($jsondata);
What is the benefit of the header? It encodes the data, but doesn't appear to have any visual effects in the various browsers that I tested it. I've also seen it break a fileupload plugin (Valum's I think but don't recall). Lastly, if my server is only returning true/false (or 1/0, or success/null), should I still encode the response?
So, to recap my question, when and why should Content-Type be application/json?
Simple: the content-type should be application/json whenever you're serving JSON data. It's just a matter of declaring the data properly, like having the right license plates on your car or an ingredients list on a bag of chips.
Whether there is a visual representation of the data in the browser is another issue, that's not the main reason why you serve a content type. (I know of no browser that shows a nice tree view for JSON data. It would be nice though!)
Lastly, if my server is only returning true/false (or 1/0, or success/null), should I still encode the response?
It depends on what the client expects, but the best policy is usually to be consistent in what you output, i.e. always JSON encode it if your other services use JSON encoding as well.
I tend to use the header when the data is in-fact JSON. That is to say looks like {...} or [...] (or, in this instance, it's served using json_encode).
Also, it probably doesn't have any effect on a browser because most (without a plugin) render it as straight text, but does make it more concise what the data it returning. Also, libraries like jQuery use this header to process the response (if it's not manually supplied in the call).
It should force the browser to try to download it as a .json file. Javascript (JQuery for example) will parse it as json rather than text/html.
I have developed a free shopping cart plug-in for small websites, I am currently using name=value&name=value to submit items to the basket.
The process is html form -> jQuery serialize -> AJAX post -> php,
I have read that JSON is a more secure way to pass this data. I was hoping some kind person could explain to me why this is or point me to any web resources on the subject.
JSON posted with XHR is no more (or less) secure than any other request.
They all must be handled appropriately.
There's no difference between AJAX POST or any other POST. It's all the same.
HTTP is a simple protocol, whether JavaScript sends headers or a custom built script - it doesn't matter to the underlying server since all it sees is plain text that it interprets.
There's no "more" security if you use AJAX or regular POST-ing, anyone can send any sort of data to the target script so you need to handle it properly.
It's not related to security at all.
JSON is just a different way to transmit the data - instead of posting a querystring-like string you send a string that is valid JSON.
By default in AJAX, data is posted in xml format using some protocol. while parsing data from xml format, we will get all node values in string format. Hence data type of the value submitted/received is not known. If required we need to typecast the data.
where as in JSON format data types has been persisted till some extent.
POSTing JSON data requires that certain types of headers be sent back and forth between the client and server. For instance, the client needs to send content type, the server needs to respond with allow-options for content type and access origin. POSTed JSON doesn't come through the PHP $_POST variable, rather it is carried in $HTTP_RAW_POST_DATA.
Without the proper headers, a browser kills the response and its data, preventing the page from looking at or processing anything. Or at least, it's supposed to.
Is generally more "secure" for preventing cross site scripting problems, but the data and calls are still subject to hacking the posted data and headers and such.
I know want to know what happens behind the scene of a HTTP post method.
i.e browser sends a HTTP post request to a server side script in PHP (eg).
How does PHP's $_POST variable get the values from the client.
Could someone explain in details or point to a guide.
The HTTP protocol(*) specifies how the browser should send the request.
HTTP basically consists of a set of headers in plain text, separated by line feeds, followed by the data being transmitted. Inside the HTTP request, POST data is actually formatted pretty much the same as GET data; it's just in a different part of the HTTP headers.
You can use tools like Firebug or Fiddler to see exactly how the headers and data are formatted for incoming and outgoing HTTP requests. It's actually all quite simple to read, so you should be able to work it out just by looking.
Once it gets to the server, the PHP interpreter is responsible for translating the raw HTTP request data into its standard $_GET, $_POST, etc variables. This is something that PHP does for you.
Other languages (eg Perl) do not have this functionality built in, so a Perl programmer would have to have code in their program to parse the incoming request data into useful variables. Fortunately, even Perl has a standard library which can be included that does the job, so even Perl programmers don't generally have to write the code themselves any more.
The way PHP, and any other language, does it is simply string manipulation. As I said, the HTTP data is plain text and is received in simple string format, so it's just a case of breaking it down by splitting it on question mark and equal sign characters.
As PHP does it all behind the scenes, you probably don't need to worry about the exact mechanisms it uses, but the PHP source code is available if you really want to find out.
I said it's all in plain text. HTTPS, of course, is encrypted. However by the time PHP gets hold of it, the Apache server has already done the decryption, so as far as PHP is concerned it's still plain text.
(*) Before anyone pulls me up on it, yes, I know that saying "HTTP protocol" is a redundancy, like "ATM machine" or "PIN number".
The browser encodes the data according to the content-type of the form, then transmits it as the body of a POST request. PHP then picks it up and populates $_POST with the names and values (performing special handling when the name includes the characters [ and ] or .).
I'd suggest to get a capturing proxy (e.g. Fiddler) or a network capture tool (e.g. Wireshark) and watch your own browsing traffic for a while; it will give you a nice view of the issue.
Other than that, POST is rather similar to GET, except that the data is sent in the body of the request instead of the URL, and there are two ways to encode them (multipart-form-data in addition to the urlencode that's shared with GET)
Well, let's ilustrate step by step, starting with a page containing a [form action="foo.php" method="post"]
Once you click submit (or hit enter), browser will trigger an event named "submit". This event can be catched internally for processing with javascript/dom, and this is what most sites do for validation or Ajax routines.
If routines does not stop the flow with a return false, browser continues to process the post request (this process is the same as making a post with XMLHttpRequest Object).
Browser will check first method, action and content encoding, then parse inputs values to know the size of data it will send, and encode it.
Finally it send something like this (raw values):
POST /foo.php HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded
Content-Length: 7
foo=bar
This is a POST request. But note that it can send content-length and send variables in chunks. Browser and server know this can happen (this is the POST method purpose). When a server receives a POST request, it keeps listening to the browser until the content received match the informed content length.
Now the other side. Server receives the request, listen the content, parse it (foo = bar; xxx = baz), and make it available on its environment for that specific request, thus you can catch it with PHP or Python, or Java...
That's it. Ah note you can pass both GET and POST variables in the same request!
Using a [form action="foo.php?someVar=123&anotherVar=TRUE" method="post"]
Will make the browser send the request as
POST /foo.php?someVar=123&anotherVar=TRUE HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded
Content-Length: 7
foo=bar
And server when parsing this request will make the following variables available:
GET[someVar] = 123
GET[anotherVar] = TRUE
POST[foo] = bar