HTTP Requests

An HTTP request consists of multiple lines, each terminated with a carriage return character (CR) followed by a line feed character (LF). It begins with a request line. This line starts with a request method¹, specifying the action to be performed on a resource. This is followed by a Uniform Resource Identifier (URI)², a string that identifies the resource on which the method will operate. The line ends with a string identifying the protocol being used.

For example, consider

GET /index.html HTTP/1.1

This uses version 1.1 of the protocol and invokes the GET method (see below), requesting the resource index.html located at the root of the tree of documents managed by the web server handling this request.

After the request line comes the header, consisting of one or more lines that specify header fields. Each field consists of a case-insensitive field name, followed by a colon, followed by the field’s value. At a minimum, there will be a header field like this:

Host: www.example.com

This provides the domain name of the web server to which the request has been directed.

The third required element of a request is an empty line—i.e., a line that consists only of the CR and LF characters.

The fourth element, a message body, is optional. Many requests won’t have a body, but if data needs to be sent with a request, the body is typically where it goes. For example, if a form on a web page makes a POST request, the contents of the form will be included in the message body.

GET & POST Methods

The most common methods encountered in web applications are GET and POST.

The GET method is designed to fetch a resource from the server without changing anything on the server. GET requests should not contain a body, but can still carry limited amounts of data from client to server by encoding that data into the URL.

For example, a search form on a web page could send the chosen search term to the server by encoding it into the URL of a GET request. The server would respond with the results of the search. Nothing would change on the server as a result of doing the search.

The POST method can be used to send data, encoded in the message body, to the server. The type of data being sent is specified using the Content-Type header field.

POST is most commonly used when sending form data from a browser to a server, where the intention is for the server to be somehow modified as a result. For example, if a user is registering as a new customer of an e-commerce site, then the database on the server side will be modified as a result of user registration, so POST should be used to deliver the details that they have entered into the registration form.

Task 3.2

Create a file named form.html, containing the following:

<!DOCTYPE html>
<html lang="en">
<head>
  <title>Form Demo</title>
</head>
<body>
  <h1>Form Demo</h1>
  <form method="GET" action="https://httpbin.io/dump/request">
    <label for="email_id">Enter your email:</label>
    <input id="email_id" type="email" name="email">
    <input type="submit" value="Subscribe!">
  </form>
</body>
</html>

Open this file in a web browser. Enter an email address in the input field and click the Subscribe button. The server should echo the details of the request back to the browser.

Look at the first line of the response. This shows you the request line of the browser’s original GET request. You should see something like the following, where the specified email address has been encoded into the URL, after the ? character:
```
GET /dump/request?email=nick%40example.com HTTP/1.1
```
The %40 is the URL encoding of the @ character. This is needed because there are restrictions on the characters allowed in URLs.

You should see only HTTP headers displayed. There is no body supplied with a GET request.
Click the Page Refresh button of the browser. This will resubmit the request made by the form. You should see the Cache-Control header appear the first time you do this. The browser has recognized that this is a repeat of an earlier request, and the header essentially instructs the server not to use a previously cached result.

The key point here is that resubmission of the request was immediately allowed. This is probably NOT what you want to happen if form submission is supposed to modify a database on the server side!
Now edit form.html, changing method="GET" to method="POST". Reload the file in the browser and try submitting again from the form.

This time, notice that the request line no longer contains the form data:
```
POST /dump/request HTTP/1.1
```
If you look at the bottom of the page, you should see the request now has a body, consisting of the form data:
```
email=nick%40example.com
```
Click the Page Refresh button. This time, you should get a warning from the browser to confirm form resubmission.

Browsers display this warning because POST requests are expected to change things on the server, so an accidental page refresh might have undesirable consequences such as updating a database twice.

Other Methods

There are seven other HTTP methods. We discuss three of them briefly below.

HEAD

The HEAD method behaves like GET, except that it retrieves only the response header and not the content of the requested resource. This allows a web client to access the metadata of that resource without having to download a potentially large amount of data.

For example, you could use a HEAD request to find out how big a video file is and check there is sufficient space for it before attempting to download it using a GET request.

PUT

The PUT method creates a new resource on the server using the content provided in the request body, or it replaces the specified resource with the content provided in the request body. Note that browsers do not make PUT requests; they use POST to send data back to a server.

Unlike POST, PUT requests are idempotent, meaning that the effect of making the same PUT request multiple times is no different than the effect of making it once.

A PUT request will trigger one of three possible responses if it succeeds:

A 201 Created response means that a new resource was created. The response header will include a Content-Location field confirming the location.
A 204 No Content or 200 OK response means that the resource already existed and it was modified using the data provided in the request.

DELETE

The DELETE method requests that the server delete the specified resource. Like PUT, it isn’t used by browsers, but is intended for use by other kinds of web client.

A DELETE request will trigger one of three possible responses if it succeeds:

A 200 OK response means that deletion succeeded, with further information provided via the response body.
A 202 Accepted response means that deletion is pending and will probably succeed, with further information provided via the response body.
A 204 No Content response means that deletion succeeded but no further information has been provided via the response body.

HTTP methods are sometimes described as verbs, underlining the fact that they represent actions to be performed by the server. ↩
URIs are a more general concept than URLs. A URL (Uniform Resource Locator) refers specifically to a resource located on a network or filesystem. Every URL is also a URI, but the reverse is not necessarily true. ↩

Keyboard shortcuts