HTTP 101

Prefetch

What happens when you type an address into the search bar and hit enter:

1. The browser extracts the domain name from the search bar.
2. The users Domain Name System (DNS) cache is queried. If no previous entries are found a DNS request is sent via your configured DNS server.
3. After getting the IP address via DNS, the host will initiate a TCP connection with that address.
4. If the connection is successful, a response will be sent from the server and its data will be rendered using HTTP.

For a more detailed explanation of DNS resolution in step 2, check out my post on the subject.

HTTP

Hyper-Text Transfer Protocol (HTTP) is an application layer protocol for communications between a client and web server. It operates on a request-response model with the client initiating any connection to the server.

HTTP Methods

Each request starts with a HTTP method which defines the request semantics, indicating the purpose of the clients request and what the client expects in a successful response. More succinctly, the method tells the server what sort of data it is sending or wants to receive. The server can then respond appropriately to the request.

The nine methods available are listed below.

GET

The most common request, it broadly asks the remote host to send the requested data back to the client. In general, GET requests will retrieve the data from a Uniform Request Identifier (URI).

Responses to a GET request are cacheable, meaning a cache can elect to use the it on subsequent GET and HEAD requests.

HEAD

Very similar to the GET request except that it only retrieves the header information. All body content is omitted.

Responses to a HEAD request are cacheable, meaning a cache can elect to use the it on subsequent GET and HEAD requests.

POST

A POST request will typically be sent via a HTML form and will effect some change on the server. According the specification it is indicated by the Content-Type header.

Common POST actions are things like adding new users, or payment processing. The POST sends that information to the server for it to be processed and declares the scheme it will use to send the data. The server needs this information so it knows how to handle the request.

Schemes:

• application/x-www-form-urlencoded
• multipart/form-data
• application/json

Example:

# Request
POST /payments HTTP/1.1
Host: bank.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 34

accountNumber=123&amount=9999&toAccount=789

Successful POST requests should get a 201 Created response and a Location header pointing to the data’s new URI.

# Response
HTTP/1.1 201 Created
Location: /payments/<ID>/<transactionID>

PUT

Similar to a POST request, a PUT references an already existing entity, and requests a update to it. The server must verify the validity of the data to be updated, and is not obligated to action the request.

Every PUT is idempotent whereas POST requests are not. Each POST will have an updating effect on the data. For instance, repeatedly sending a POST on endpoints like payment processing could see that payment processed as many times as the request was sent. This is one of the differences between the two at the HTTP level. But, the most important difference is how the each request interacts with the URI it is requesting.

A PUT request must know the exact URI it intends to influence.

For example:

# Updates an existing record 
# OR adds a record to that exact URI
PUT /api/v1/books/3452 HTTP/1.1
Host: https://library-store.com/

Should return a 200 OK or in some cases a 201 Created.

REST API’s usually adhere to the correct use of PUT and POST requests. A URI such as above is a good indication of a REST conforming web application.

PATCH

Unlike PUT which will replace an existing entity, PATCH only modifies a portion of it. This makes it an non-idempotent method. Similar to POST, it will make alterations or add data for each request. However, a PATCH can be made idempotent - it depends on context and the data being modified.

This method is relatively new in comparison to its siblings, having been introduced as early as RFC 2616 but only being ratified in RFC 5789 circa 2010.

# Request
PATCH /file.txt HTTP/1.1
Host: www.example.com
Content-Type: application/example
If-Match: "e0023aa4e"
Content-Length: 100

A successful response generally yields a 204 No Content as no message body is present. A 200 OK requires a message body. Other codes can be configured by the server if required.

# Response
HTTP/1.1 204 No Content
Content-Location: /file.txt
ETag: "e0023aa4f"

Note how the If-Match and ETag data match. This will be covered in a later post.

DELETE

Is a request to the server that calls a function capable of deleting a specified entity. The server is responsible for checking and carrying out the function.

# Request
DELETE /user/2341 HTTP/1.1

Should return a 202 Accepted, 204 No Content or 200 OK.

TRACE

An uncommon request that is often seen during diagnostics such as Traceroute. Can see what the server was delivered.

Often this method is disabled as its an attack vector for Cross Site Tracing.

CONNECT

For use with a proxy to initiate the connection.

OPTIONS

A utility call that asks the server which HTTP methods are supported.

The allow header shows which options are authorized. Some applications prohibit the OPTIONS method and will return a 4XX status code.

HTTP/2 200 
allow: OPTIONS, GET, HEAD, POST
cache-control: max-age=604800
content-type: text/html; charset=UTF-8
date: Sun, 14 Jul 2019 05:17:14 GMT
expires: Sun, 21 Jul 2019 05:17:14 GMT
server: EOS (vny006/044F)
content-length: 0

Summary

Digging into the HTTP specifications and RFC’s has not been wasted effort. They underpin the Internet and all associated technologies that power it. Learn some for great good.