In computing, POST is one of many request methods supported by the HTTP protocol used by the World Wide Web. The POST request method is designed to request that a web server accept the data enclosed in the request message's body for storage. It is often used when uploading a file or submitting a completed web form.
In contrast, the HTTP GET request method is designed to retrieve information from the server. As part of a GET request, some data can be passed within the URI's query string, specifying for example search terms, date ranges, or other information that defines the query. As part of a POST request, an arbitrary amount of data of any type can be sent to the server in a request message body. A header field in the POST request usually indicates the message body's Internet media type.
The World Wide Web and HTTP are based on a number of request methods or 'verbs', including POST and GET as well as PUT, DELETE, and several others. Web browsers normally use only GET and POST, but RESTful online apps make use of many of the others. POST's place in the range of HTTP methods is to send a representation of a new data entity to the server so that it will be stored as a new subordinate of the resource identified by the URI. For example, for the URI
http://example.com/customers, POST requests might be expected to represent new customers, each including their name, address, contact details and so on. Early website designers strayed away from this original concept in two important ways. First, there is no technical reason for a URI textually to describe the web resource subordinate to which POST data will be stored. In fact, unless some effort is made, the last part of a URI will more likely describe the web application's processing page and its technology, such as
http://example.com/applicationform.php. Secondly, given most web browsers' natural limitation to use only GET or POST, designers felt the need to re-purpose POST to do many other data submission and data management tasks, including the alteration of existing records and their deletion.
Efforts by some influential writers to remedy the first point began as early as 1998. Web application frameworks such as Ruby on Rails and others make it easier for designers to provide their users with clean URLs. With regard to the second point, it is possible to use client-side scripting, or to write standalone apps, to make use of the other HTTP methods where they are relevant, but outside of this most web forms that submit or alter server data will continue to use POST for the purpose.
That is not to say that every web form should specify
method="post" in its opening tag. Many forms are used to specify more precisely the retrieval of information from the server, without any intention of altering the main database. Such search forms are ideally suited to having
There are times when HTTP GET is less suitable even for data retrieval. An example of this is when a great deal of data would need to be specified in the URL. Browsers and web servers can have limits on the length of the URL that they will handle without truncation or error. Percent-encoding of reserved characters in URLs and query strings can significantly increase their length, and while Apache HTTP Server can handle up to 4,000 characters in a URL, Microsoft Internet Explorer is limited to 2048 characters in any URL. Equally, HTTP GET should not be used where sensitive information, such as user names and passwords have to be submitted along with other data for the request to complete. Even if HTTPS is used, preventing the data from being intercepted in transit, the browser history and the web server's logs will likely contain the full URL in plaintext, which may be exposed if either system is hacked. In these cases, HTTP POST should be used.
Use for submitting web forms
When a web browser sends a POST request from a web form element, the default Internet media type is "application/x-www-form-urlencoded". This is a format for encoding key-value pairs with possibly duplicate keys. Each key-value pair is separated by an '&' character, and each key is separated from its value by an '=' character. Keys and values are both escaped by replacing spaces with the '+' character and then using URL encoding on all other non-alphanumeric characters.
For example, the key-value pairs
Name: Jonathan Doe Age: 23 Formula: a + b == 13%!
are encoded as
Starting with HTML 4.0, forms can also submit data in multipart/form-data as defined in RFC 2388 (See also RFC 1867 for an earlier experimental version defined as an extension to HTML 2.0 and mentioned in HTML 3.2).
The special case of a POST to the same page that the form belongs to, is known as a postback.
Affecting server state
Per RFC 7231, the POST method should be used for any context in which a request is non-idempotent: that is, it causes a change in server state each time it is performed, such as submitting a comment to a blog post or voting in an online poll. GET is defined to be nullipotent, with no side-effects (in contrast to "no side effects on second or future requests" as with idempotent operations). For this reason, web crawlers such as search engine indexers normally use the GET and HEAD methods exclusively, to prevent their automated requests from performing such actions.
However, there are reasons why POST is used even for idempotent requests, notably if the request uses non-ASCII characters or is very long, due to restrictions on URLs – the query string in the GET method may become very long, especially due to percent-encoding. Webhooks use POST mostly to circumvent the length restrictions.
- "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content". Retrieved 2014-07-24. "The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics."
- Berners-Lee, Tim (1998). "Cool URIs don't change". W3C. Retrieved 17 October 2012.
- Friedman, Mike (2009). "Using HTTP PUT and DELETE methods in web applications". Retrieved 17 October 2012.
- "Form submission". HTML 4.01 Specification. W3C. 1999. Retrieved 17 October 2012.
- Rigsby, Dan (2008). "REST and Max URL Size". Retrieved 17 October 2012.
- "Maximum URL length is 2,083 characters in Internet Explorer". Microsoft.
- "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content". RFC 7231. Retrieved 2014-07-25.
- Berners-Lee, Tim; Connolly, Dan (22 September 1995). "Hypertext Markup Language - 2.0 - Forms". World Wide Web Consortium. Retrieved 15 January 2011.
- "Forms in HTML documents".
- Korpela, Jukka (28 September 2003). "Methods GET and POST in HTML forms - what's the difference?". Tampere University of Technology. Retrieved 15 January 2011.
- RFC 7231, 4.2.1 Safe Methods