uri $http.post - How are parameters sent in an HTTP POST request?
angularjs example (8)
Some of the webservices require you to place request data and metadata separately. For example a remote function may expect that the signed metadata string is included in a URI, while the data is posted in a HTTP-body.
The POST request may semantically look like this:
POST /?AuthId=YOURKEY&Action=WebServiceAction&Signature=rcLXfkPldrYm04 HTTP/1.1 Content-Type: text/tab-separated-values; charset=iso-8859-1 Content-Length:  Host: webservices.domain.com Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: identity User-Agent: Mozilla/3.0 (compatible; Indy Library) name id John G12N Sarah J87M Bob N33Y
This approach logically combines QueryString and Body-Post using a single
Content-Type which is a "parsing-instruction" for a web-server.
Please note: HTTP/1.1 is wrapped with the
#32 (space) on the left and with
#10 (Line feed) on the right.
In an HTTP GET request, parameters are sent as a query string:
In an HTTP POST request, the parameters are not sent along with the URI.
Where are the values? In the request header? In the request body? What does it look like?
The default media type in a POST request is
application/x-www-form-urlencoded. This is a format for encoding key-value pairs. The keys can be duplicate. Each key-value pair is separated by an
& character, and each key is separated from its value by an
Name: John Smith Grade: 19
Is encoded as:
This is placed in the request body after the HTTP headers.
The values are sent in the request body, in the format that the content type specifies.
Usually the content type is
application/x-www-form-urlencoded, so the request body uses the same format as the query string:
When you use a file upload in the form, you use the
multipart/form-data encoding instead, which has a different format. It's more complicated, but you usually don't need to care what it looks like, so I won't show an example, but it can be good to know that it exists.
Short answer: in POST requests, values are sent in the "body" of the request. With web-forms they are most likely sent with a media type of
multipart/form-data. Programming languages or frameworks which have been designed to handle web-requests usually do "The Right Thing™" with such requests and provide you with easy access to the readily decoded values (like
$_POST in PHP, or
flask.request.form in Python).
Now let's digress a bit, which may help understand the difference ;)
The difference between
POST requests are largely semantic. They are also "used" differently, which explains the difference in how values are passed.
GET (relevant RFC section)
When executing a
GET request, you ask the server for one, or a set of entities. To allow the client to filter the result, it can use the so called "query string" of the URL. The query string is the part after the
?. This is part of the URI syntax.
So, from the point of view of your application code (the part which receives the request), you will need to inspect the URI query part to gain access to these values.
Note that the keys and values are part of the URI. Browsers may impose a limit on URI length. The HTTP standard states that there is no limit. But at the time of this writing, most browsers do limit the URIs (I don't have specific values).
GET requests should never be used to submit new information to the server. Especially not larger documents. That's where you should use
POST (relevant RFC section)
When executing a
POST request, the client is actually submitting a new document to the remote host. So, a query string does not (semantically) make sense. Which is why you don't have access to them in your application code.
POST is a little bit more complex (and way more flexible):
When receiving a POST request, you should always expect a "payload", or, in HTTP terms: a message body. The message body in itself is pretty useless, as there is no standard (as far as I can tell. Maybe application/octet-stream?) format. The body format is defined by the
Content-Type header. When using a HTML
FORM element with
method="POST", this is usually
application/x-www-form-urlencoded. Another very common type is multipart/form-data if you use file uploads. But is could be anything, ranging from
application/json or even a custom
In any case, if a
POST request is made with a
Content-Type which cannot be handled by the application, it should return a
Most programming languages (and/or web-frameworks) offer a way to de/encode the message body from/to the most common types (like
application/json). So that's easy. Custom types require potentially a bit more work.
Using a standard HTML form encoded document as example, the application should perform the following steps:
- Read the
- If the value is not one of the supported media-types, then return a response with a
- otherwise, decode the values from the message body.
Again, languages like PHP, or web-frameworks for other popular languages will probably handle this for you. The exception to this is the
415 error. No framework can predict which content-types your application chooses to support and/or not support. This is up to you.
PUT (relevant RFC section)
PUT request is pretty much handled in the exact same way as a
POST request. The big difference is that a
POST request is supposed to let the server decide how to (and if at all) create a new resource. Historically (from the now obsolete RFC2616 it was to create a new resource as a "subordinate" (child) of the URI where the request was sent to).
PUT request in contrast is supposed to "deposit" a resource exactly at that URI, and with exactly that content. No more, no less. The idea is that the client is responsible to craft the complete resource before "PUTting" it. The server should accept it as-is on the given URL.
As a consequence, a
POST request is usually not used to replace an existing resource. A
PUT request can do both create and replace.
There are also "path parameters" which can be used to send additional data to the remote, but they are so uncommon, that I won't go into too much detail here. But, for reference, here is an excerpt from the RFC:
Aside from dot-segments in hierarchical paths, a path segment is considered opaque by the generic syntax. URI producing applications often use the reserved characters allowed in a segment to delimit scheme-specific or dereference-handler-specific subcomponents. For example, the semicolon (";") and equals ("=") reserved characters are often used to delimit parameters and parameter values applicable to that segment. The comma (",") reserved character is often used for similar purposes. For example, one URI producer might use a segment such as "name;v=1.1" to indicate a reference to version 1.1 of "name", whereas another might use a segment such as "name,1.1" to indicate the same. Parameter types may be defined by scheme-specific semantics, but in most cases the syntax of a parameter is specific to the implementation of the URIs dereferencing algorithm.
You cannot type it directly on the browser URL bar.
You can see how POST data is sent on the Internet with Live HTTP Headers for example. Result will be something like that
http://127.0.0.1/pass.php POST /pass.php HTTP/1.1 Host: 127.0.0.1 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate DNT: 1 Referer: http://127.0.0.1/pass.php Cookie: passx=87e8af376bc9d9bfec2c7c0193e6af70; PHPSESSID=l9hk7mfh0ppqecg8gialak6gt5 Connection: keep-alive Content-Type: application/x-www-form-urlencoded Content-Length: 30 username=zurfyx&pass=password
Where it says
Content-Length: 30 username=zurfyx&pass=password
will be the post values.
First of all, let's differentiate between
Get: It is the default
HTTP request that is made to the server and is used to retrieve the data from the server and query string that comes after
? in a
URI is used to retrieve a unique resource.
this is the format
GET /someweb.asp?data=value HTTP/1.0
data=value is the query string value passed.
POST: It is used to send data to the server safely so anything that is needed, this is the format of a
POST /somweb.aspHTTP/1.0 Host: localhost Content-Type: application/x-www-form-urlencoded //you can put any format here Content-Length: 11 //it depends Name= somename
Why POST over GET?
GET the value being sent to the servers are usually appended to the base URL in the query string, This makes your data able to be hacked (this was a problem back in days for Facebook where your credentials were exposed) that is why
POST is used to send data to the server which used
Request Body to send your data to the server which is more secure because it hides your data plus it gets your data from the fields calculate the length of them and add them to the
content-length and no important data is directly appended to the
now that your request is made secure any values being sent to the server can be sent in the
Request Body as the name implies it will contain the data user wanted to send (and It is sent in the
URL Encoded format) and the
Request Headers will keep the Request secure by comparing the values in the
Request Body with the
You can use the Google Developer Tools' network section to see basic information about how requests are made to the servers.
and you can always add more values in your
Request Headers like
The content is put after the HTTP headers. The format of an HTTP POST is to have the HTTP headers, followed by a blank line, followed by the request body. The POST variables are stored as key-value pairs in the body.
You can see this in the raw content of an HTTP Post, shown below:
POST /path/script.cgi HTTP/1.0 From: [email protected] User-Agent: HTTPTool/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 32 home=Cosby&favorite+flavor=flies
You can see this using a tool like Fiddler, which you can use to watch the raw HTTP request and response payloads being sent across the wire.
-D, --dump-header <file> Write the protocol headers to the specified file. This option is handy to use when you want to store the headers that a HTTP site sends to you. Cookies from the headers could then be read in a second curl invocation by using the -b, --cookie option! The -c, --cookie-jar option is however a better way to store cookies.
-S, --show-error When used with -s, --silent, it makes curl show an error message if it fails.
-L/--location (HTTP/HTTPS) If the server reports that the requested page has moved to a different location (indicated with a Location: header and a 3XX response code), this option will make curl redo the request on the new place. If used together with -i/--include or -I/--head, headers from all requested pages will be shown. When authentication is used, curl only sends its credentials to the initial host. If a redirect takes curl to a different host, it won’t be able to intercept the user+password. See also --location-trusted on how to change this. You can limit the amount of redirects to follow by using the --max-redirs option. When curl follows a redirect and the request is not a plain GET (for example POST or PUT), it will do the following request with a GET if the HTTP response was 301, 302, or 303. If the response code was any other 3xx code, curl will re-send the following request using the same unmodified method.
from the man page. so
curl -sSL -D - www.acooke.org -o /dev/null
follows redirects, dumps the headers to stdout and sends the data to /dev/null (that's a GET, not a POST, but you can do the same thing with a POST - just add whatever option you're already using for POSTing data)
- after the
-D which indicates that the output "file" is stdout.