HTTP, the HyperText Transfer Protocol, is one of the protocols at the heart of the Internet. Messages always come in pairs: a request receives a response.

Methods (verbs)

HTTP exposes a number of methods, used to indicate the type of action to perform. By convention:

  • GET reads a resource and returns its content and metadata.
  • HEAD reads and returns just the metadata (headers).
  • POST creates a new resource.
  • PUT updates a resource in place.
  • DELETE removes a resource.
  • TRACE provides loop-back testing by reflecting a returned response to a server.

The HTTP specification allows extension through addition of HTTP verbs, a property exploited by WebDAV to provide filesystem semantics atop HTTP.

Safe requests are read-only (GET, HEAD): there should be no risk of modification to a resource if the request is replayed. Browsers will ask users to confirm resubmission.


WebDAV provides a virtual file system atop HTTP defined in RFC 4918. It reuses the existing HTTP methods:

  • GET
  • HEAD
  • POST
  • PUT

It also extends HTTP with domain-specific methods:

  • OPTIONS provides discovery of WebDAV support.
  • COPY copies an existing resource to a new location.
  • MOVE moves an existing resource to a new location.
  • MKCOL creates a collection.
  • LOCK locks a resource.
  • UNLOCK unlocks a resource.
  • PROPFIND gets a resource's property.
  • PROPPATCH modifies a resource's properties.



Uniform Resource Locals uniquely identify HTTP resources. They're defined in RFC 3986.


URL encoding encodes "unsafe characters" outside of the ASCII plane with their encoded equivalents:

CharacterEncoded form
Exclamation mark (!)%21
Double quote (")%22
Hash (#)%23
Dollar ($)%24
Percent (%)%25
Ampersand (&)%26


Content types are indicated in the form of MIME types using the Content-Type response header.

Resources might be expressed in a number of different representations via negotiations:

  • Accept: text/html,application/xhtml+xml,*/* indicates a preferred response format of HTML, but acceptance of everything.
  • Accept-Language: en-GB indicates a preference for British English.

Request format

GET / HTTP/1.1
Connection: close

Request headers

  • Connection: keep-alive specifies that the browser wants the server to keep the connection open after sending a response so that another request can be sent.
  • Cookie: name=value; param lets a client send a cookie back to the server.
  • Host: allows "virtual hosting": hosting multiple websites on the same IP address.

Response format

HTTP/1.1 200 OK
Content-Length: 22
Content-Type: text/html
Date: Sat, 19 Sep 2020 21:29:29 GMT

<h1>Hello, world!</h1>


Connection header:

  • close immediately terminates the connection upon delivery of the response.
  • keep-alive keeps the connection open once the initial request/response flow is complete, allowing reuse.

User agents (browsers) will aggressively download resources over multiple open connections

Pipelining allows a user agent to request multiple resources over a single HTTP connection without waiting for a response.


  • Forward proxies relay requests to external servers.
    • As content filters
    • For privacy, e.g. stripping referer headers
  • Reverse proxies are closer to the server and are typically invisible to clients.
    • Compression
    • Load balancing


Cookies extend HTTP with a basic form of session state. They're typically used to store user preferences or authentication tokens that can be matched to a server-side session, allowing crossing the 4KB size limit.

Servers can set cookies in response headers:

Set-Cookie: name=value;; path=/

The client will send relevant cookies in requests:

Cookie: name=value

Cookies can be set with a number of optional parameters:

  • path=/ constrains the cookie to all paths below the root, but could indicate a specific resource.
  • determines the relevant domain. The leading . allows access to and subdomains.
  • HttpOnly prevents access to the cookie via JavaScript (Private)'s document.cookie, thus preventing XSS.
  • Secure sends the cookie over encrypted transports.
  • SameSite=Strict only sends cookies if requests originate from the same domain, preventing CSRF. Lax enforces the target domain. None allows third-party cookies.


HTTP performs authentication via challenge-response sequence.

  1. Client requests GET /private/resource.
  2. Server responses with 401 Unauthorized, setting the WWW-Authenticate header.
  3. The browser prompts for authentication credentials, which are then transmitted to the server in the Authorization header.

There are two types of authentication.


Basic authentication uses a pre-shared key, transmitted over the wire in base64-encoded cleartext with every request. The server will request authentication as follows:

WWW-Authenticate: Basic realm="Protected area"

The client should respond: with the base64-encoded username and password pair, delimited by a colon (admin:hunter2 in the below) example:

Authorization: Basic YWRtaW46aHVudGVyMgo=


Digest authentication goes some way toward protecting the password in transit by having the client compute an MD5 hash of the password using a nonce value it controls.

The hash is computed using the following sequence:

ha1 = md5(username:realm:password)
ha2 = md5(method:digestUri)
response = md5(ha1:nonce:ha2)

The server's challenge looks like:

WWW-Authenticate: Digest realm="Protected area" qop="auth,auth-int" nonce="" opaque=""

And the hash is returned via the following request:

Authorize: Digest xxx


URL canonicalisation ensures a service is accessed only via a single host.


  1. Caching
  2. Extended Log file format
  3. Kong
  4. Media (MIME) types
  5. OpenResty
  6. REST
  7. Response statuses
  8. SOAP
  9. W3C Trace Context
  10. nginx