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);
Related
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.
I have a CI controller that outputs some JS variables (mainly language variables). I set the MIME type using header function, etc. So, it's really JS when it's outputted.
Looking at the header responses, I see session data being returned. As an optimization, I would like to prevent that from being returned (saved a few bytes). Is there a way for me to do this?
For my regular JS, CSS, etc. files, I put them on a sub-domain that does not set session/cookies. But since JS this is coming from my application's controller, it has session data.
As long as headers (which cookies are) have not been sent already, the header_remove function can be used to remove them before they are send to the browser.
It might be that this makes especially sense as codeigniter sends all session data as a round-trip.
To inspect outgoing headers, PHP's headers_list function is handy.
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
I ran into this problem when scraping sites with heavy usage of javascript to obfuscate it's data.
For example,
"a href="javascript:void(0)" onClick="grabData(23)"> VIEW DETAILS
This href attribute, reveals no information about the actual URL. You'd have to manually look and examine the grabData() javascript function to get a clue.
OR
The old school way is manually opening up Live HTTP header add on for firefox, and monitoring the POST perimeters, which reveals the actual URL being POSTed.
So i'm wondering, is there a way to capture the POST parameters in a server side script or Javscript, as Live HTTP header does, for the outgoing and incoming POST parameters? This would make even the most javscript obfuscated web pages easily scrapable.
thanks.
I'm not sure I understand the question but...
In PHP, incoming POST parameters are stored in the $_POST array, you can display them with print_r($_POST);.