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.
HTTP exposes a number of methods, used to indicate the type of action to perform. By convention:
GETreads a resource and returns its content and metadata.
HEADreads and returns just the metadata (headers).
POSTcreates a new resource.
PUTupdates a resource in place.
DELETEremoves a resource.
TRACEprovides 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 (
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:
It also extends HTTP with domain-specific methods:
OPTIONSprovides discovery of WebDAV support.
COPYcopies an existing resource to a new location.
MOVEmoves an existing resource to a new location.
MKCOLcreates a collection.
LOCKlocks a resource.
UNLOCKunlocks a resource.
PROPFINDgets a resource's property.
PROPPATCHmodifies 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:
|Exclamation mark (|
|Double quote (|
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-GBindicates a preference for British English.
GET / HTTP/1.1 Connection: close
Connection: keep-alivespecifies 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; paramlets a client send a cookie back to the server.
Host: example.comallows "virtual hosting": hosting multiple websites on the same IP address.
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>
closeimmediately terminates the connection upon delivery of the response.
keep-alivekeeps 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
- Reverse proxies are closer to the server and are typically invisible to clients.
- 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; domain=.example.com; path=/
The client will send relevant cookies in requests:
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.
domain=.example.comdetermines the relevant domain. The leading
.allows access to
document.cookie, thus preventing XSS.
Securesends the cookie over encrypted transports.
SameSite=Strictonly sends cookies if requests originate from the same domain, preventing CSRF.
Laxenforces the target domain.
Noneallows third-party cookies.
HTTP performs authentication via challenge-response sequence.
- Client requests
- Server responses with 401 Unauthorized, setting the
- The browser prompts for authentication credentials, which are then transmitted to the server in the
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.
- Extended Log file format
- Media (MIME) types
- Response statuses
- W3C Trace Context