POST (HTTP)

Last updated

In computing, POST is a request method supported by HTTP used by the World Wide Web. By design, the POST request method requests that a web server accept the data enclosed in the body of the request message, most likely for storing it. [1] It is often used when uploading a file or when submitting a completed web form.

Contents

In contrast, the HTTP GET request method retrieves information from the server. As part of a GET request, some data can be passed within the URL'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 the body of the request message. A header field in the POST request usually indicates the message body's Internet media type.

Posting data

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. [1] 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 to textually 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. [2] [ better source needed ] Web application frameworks such as Ruby on Rails and others make it easier for designers to provide their users with semantic 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, [3] but outside of this most web forms that submit or alter server data 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. Search forms, for example, are ideally suited to having method="get" specified. [4]

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, [5] Microsoft Internet Explorer is limited to 2,048 characters in any URL. [6] Equally, HTTP GET should not be used where sensitive information, such as usernames 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. [7]

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". [8] 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 percent-encoding on all other non-alphanumeric [9] characters.

For example, the key-value pairs

Name: misael a Hidalgo a Age: 35 Formula: a+b == 21 

are encoded as

Name=misael+Hidalgo &Age=35 &Formula=a%2Bb+%3D%3D+21 

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 is not idempotent, meaning that multiple identical requests might not have the same effect as transmitting the request only once. POST is therefore suitable for requests which change the state each time they are performed, for example submitting a comment to a blog post or voting in an online poll. GET is defined to be nullipotent, with no side-effects, and idempotent operations have "no side effects on second or future requests". [10] [11] 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 is very long. Due to restrictions on URLs, the query string the GET method generates may become very long, especially due to percent-encoding. [10]

Related Research Articles

In computing, Common Gateway Interface (CGI) is an interface specification that enables web servers to execute an external program to process HTTP or HTTPS user requests.

<span class="mw-page-title-main">HTTP</span> Application protocol for distributed, collaborative, hypermedia information systems

The Hypertext Transfer Protocol (HTTP) is an application layer protocol in the Internet protocol suite model for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web, where hypertext documents include hyperlinks to other resources that the user can easily access, for example by a mouse click or by tapping the screen in a web browser.

A Uniform Resource Identifier (URI) is a unique sequence of characters that identifies an abstract or physical resource, such as resources on a webpage, mail address, phone number, books, real-world objects such as people and places, concepts. URIs are used to identify anything described using the Resource Description Framework (RDF), for example, concepts that are part of an ontology defined using the Web Ontology Language (OWL), and people who are described using the Friend of a Friend vocabulary would each have an individual URI.

<span class="mw-page-title-main">World Wide Web</span> Linked hypertext system on the Internet

The World Wide Web is an information system that enables content sharing over the Internet through user-friendly ways meant to appeal to users beyond IT specialists and hobbyists. It allows documents and other web resources to be accessed over the Internet according to specific rules of the Hypertext Transfer Protocol (HTTP).

URL redirection, also called URL forwarding, is a World Wide Web technique for making a web page available under more than one URL address. When a web browser attempts to open a URL that has been redirected, a page with a different URL is opened. Similarly, domain redirection or domain forwarding is when all pages in a URL domain are redirected to a different domain, as when wikipedia.com and wikipedia.net are automatically redirected to wikipedia.org.

A query string is a part of a uniform resource locator (URL) that assigns values to specified parameters. A query string commonly includes fields added to a base URL by a Web browser or other client application, for example as part of an HTML document, choosing the appearance of a page, or jumping to positions in multimedia content.

In the context of an HTTP transaction, basic access authentication is a method for an HTTP user agent to provide a user name and password when making a request. In basic HTTP authentication, a request contains a header field in the form of Authorization: Basic <credentials>, where <credentials> is the Base64 encoding of ID and password joined by a single colon :.

<span class="mw-page-title-main">Digest access authentication</span> Method of negotiating credentials between web server and browser

Digest access authentication is one of the agreed-upon methods a web server can use to negotiate credentials, such as username or password, with a user's web browser. This can be used to confirm the identity of a user before sending sensitive information, such as online banking transaction history. It applies a hash function to the username and password before sending them over the network. In contrast, basic access authentication uses the easily reversible Base64 encoding instead of hashing, making it non-secure unless used in conjunction with TLS.

The data URI scheme is a uniform resource identifier (URI) scheme that provides a way to include data in-line in Web pages as if they were external resources. It is a form of file literal or here document. This technique allows normally separate elements such as images and style sheets to be fetched in a single Hypertext Transfer Protocol (HTTP) request, which may be more efficient than multiple HTTP requests, and used by several browser extensions to package images as well as other multimedia content in a single HTML file for page saving. As of 2024, data URIs are fully supported by all major browsers.

<span class="mw-page-title-main">Content negotiation</span> Serving multiple documents at the same URI

Content negotiation refers to mechanisms defined as a part of HTTP that make it possible to serve different versions of a document at the same URI, so that user agents can specify which version fits their capabilities the best. One classical use of this mechanism is to serve an image in GIF or PNG format, so that a browser that cannot display PNG images will be served the GIF version.

In computer hypertext, a URI fragment is a string of characters that refers to a resource that is subordinate to another, primary resource. The primary resource is identified by a Uniform Resource Identifier (URI), and the fragment identifier points to the subordinate resource.

URL encoding, officially known as percent-encoding, is a method to encode arbitrary data in a uniform resource identifier (URI) using only the US-ASCII characters legal within a URI. Although it is known as URL encoding, it is also used more generally within the main Uniform Resource Identifier (URI) set, which includes both Uniform Resource Locator (URL) and Uniform Resource Name (URN). As such, it is also used in the preparation of data of the application/x-www-form-urlencoded media type, as is often used in the submission of HTML form data in HTTP requests.

A webform, web form or HTML form on a web page allows a user to enter data that is sent to a server for processing. Forms can resemble paper or database forms because web users fill out the forms using checkboxes, radio buttons, or text fields. For example, forms can be used to enter shipping or credit card data to order a product, or can be used to retrieve search results from a search engine.

<span class="mw-page-title-main">HTTP referer</span> HTTP header field

In HTTP, "Referer" is an optional HTTP header field that identifies the address of the web page, from which the resource has been requested. By checking the referrer, the server providing the new web page can see where the request originated.

<span class="mw-page-title-main">HTTP 302</span> HTTP Status Code

The HTTP response status code 302 Found is a common way of performing URL redirection. The HTTP/1.0 specification initially defined this code, and gave it the description phrase "Moved Temporarily" rather than "Found".

<span class="mw-page-title-main">HTTP 303</span> HTTP response status code

The HTTP response status code 303 See Other is a way to redirect web applications to a new URI, particularly after a HTTP POST has been performed, since RFC 2616.

<span class="mw-page-title-main">HTTP location</span> Instruction by web server containing the intended location of a web page.

The HTTP Location header field is returned in responses from an HTTP server under two circumstances:

  1. To ask a web browser to load a different web page. In this circumstance, the Location header should be sent with an HTTP status code of 3xx. It is passed as part of the response by a web server when the requested URI has:
  2. To provide information about the location of a newly created resource. In this circumstance, the Location header should be sent with an HTTP status code of 201 or 202.

A uniform resource locator (URL), colloquially known as an address on the Web, is a reference to a resource that specifies its location on a computer network and a mechanism for retrieving it. A URL is a specific type of Uniform Resource Identifier (URI), although many people use the two terms interchangeably. URLs occur most commonly to reference web pages (HTTP/HTTPS) but are also used for file transfer (FTP), email (mailto), database access (JDBC), and many other applications.

References

  1. 1 2 Fielding, R.; Reschke, J. (2014). Fielding, R.; Reschke, J. (eds.). "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content - 4.3.3 POST". tools.ietf.org. doi:10.17487/RFC7231. S2CID   14399078 . 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.
  2. Berners-Lee, Tim (1998). "Cool URIs don't change". W3C. Retrieved 17 October 2012.
  3. Friedman, Mike (2009). "Using HTTP PUT and DELETE methods in web applications" . Retrieved 17 October 2012.
  4. "Form submission". HTML 4.01 Specification. W3C. 1999. Retrieved 17 October 2012.
  5. Rigsby, Dan (2008). "REST and Max URL Size". Archived from the original on 4 November 2012. Retrieved 17 October 2012.
  6. "Maximum URL length is 2,048 characters in Internet Explorer". Microsoft.
  7. Fielding, R.; Reschke, J. (2014). Fielding, R.; Reschke, J. (eds.). "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content - 9.4 Disclosure of Sensitive Information in URIs". RFC 7231 . doi:10.17487/RFC7231. S2CID   14399078 . Retrieved 2014-07-25.
  8. Berners-Lee, Tim; Connolly, Dan (22 September 1995). "Hypertext Markup Language - 2.0 - Forms". World Wide Web Consortium. Retrieved 15 January 2011.
  9. "Forms in HTML documents".
  10. 1 2 Korpela, Jukka (28 September 2003). "Methods GET and POST in HTML forms - what's the difference?". Tampere University of Technology . Retrieved 15 January 2011.
  11. RFC 7231, 4.2.1 Safe Methods