HTTP

HyperText Transfer Protocol — The Foundation of the Web

HTTP Request Methods
CLIENT
SERVER
GET
Safe ✓ Idempotent ✓ Cacheable ✓
Retrieves a resource without modifying it. Parameters are passed in the URL query string. The most common HTTP method — used for every page load.
GET /api/users?page=2 HTTP/1.1 Host: example.com Accept: application/json
POST
Safe ✗ Idempotent ✗ Cacheable ✗
Submits data to create a new resource. The request body contains the data. Multiple identical POST requests may create multiple resources.
POST /api/users HTTP/1.1 Content-Type: application/json {"name":"Alice","email":"a@b.com"}
PUT
Safe ✗ Idempotent ✓ Cacheable ✗
Replaces an entire resource at a given URI. If the resource doesn't exist, it may be created. The full entity must be sent in the body.
PUT /api/users/42 HTTP/1.1 Content-Type: application/json {"name":"Bob","email":"b@c.com"}
PATCH
Safe ✗ Idempotent ✗ Cacheable ✗
Applies a partial modification to a resource. Only the fields to be changed are included in the body — unlike PUT which replaces the entire resource.
PATCH /api/users/42 HTTP/1.1 Content-Type: application/json {"email":"newemail@example.com"}
DELETE
Safe ✗ Idempotent ✓ Cacheable ✗
Removes a resource. Idempotent — deleting the same resource twice produces the same outcome (resource is gone). Returns 204 on success.
DELETE /api/users/42 HTTP/1.1 Host: example.com Authorization: Bearer <token>
HEAD
Safe ✓ Idempotent ✓ Cacheable ✓
Like GET but returns only response headers, not the body. Used to check if a resource exists, get its size, or validate a cached copy without transferring data.
HEAD /files/large-video.mp4 HTTP/1.1 Host: cdn.example.com # Returns Content-Length, Last-Modified
OPTIONS
Safe ✓ Idempotent ✓ Cacheable ✗
Describes the communication options for a resource. Used heavily by CORS preflight requests to determine which methods and headers the server permits.
OPTIONS /api/data HTTP/1.1 Origin: https://app.example.com Access-Control-Request-Method: POST
CONNECT
Safe ✗ Idempotent ✗ Cacheable ✗
Establishes a tunnel to a server via a proxy. Used for HTTPS through HTTP proxies — the proxy becomes a transparent TCP relay after the 200 tunnel response.
CONNECT secure.example.com:443 HTTP/1.1 Host: secure.example.com:443 Proxy-Authorization: Basic <creds>
TRACE
Safe ✓ Idempotent ✓ Cacheable ✗
Echoes the received request back so the client can see what changes were made by intermediate proxies. Disabled by most servers due to XST (cross-site tracing) vulnerability.
TRACE / HTTP/1.1 Host: example.com # Server returns full request as-received
HTTP Status Codes
1xx — Informational
100
Continue
Server received the request headers and the client should proceed to send the body. Reduces unnecessary data transfer.
101
Switching Protocols
Server agrees to switch protocols as requested (e.g., HTTP → WebSocket). Sent in response to an Upgrade header.
2xx — Success
200
OK
The request succeeded. The response body contains the requested resource or result.
201
Created
Resource created successfully (POST). The Location header typically points to the new resource URL.
202
Accepted
Request accepted but not yet processed. Used for async operations. No guarantee of completion.
204
No Content
Success but no body to return. Typical for DELETE or PUT. The client should not update its view.
206
Partial Content
Response is a partial resource, sent in response to a Range header request. Used for resumable downloads and video streaming.
3xx — Redirection
301
Moved Permanently
Resource has permanently moved to a new URL. Browsers cache this; search engines transfer link equity.
302
Found
Temporary redirect. Client should continue using the original URL for future requests.
304
Not Modified
Resource hasn't changed since last request (ETag/If-Modified-Since validation). Use your cached copy.
307
Temporary Redirect
Temporary redirect. Unlike 302, the HTTP method must NOT change (POST stays POST).
308
Permanent Redirect
Permanent redirect. Like 301, but the method must not change. Strict version of 301.
4xx — Client Error
400
Bad Request
Server cannot process the request due to client error — malformed syntax, invalid parameters, or deceptive routing.
401
Unauthorized
Authentication required. The client must authenticate itself. Response includes a WWW-Authenticate header.
403
Forbidden
Server understood the request but refuses to authorize it. Unlike 401, authentication won't help.
404
Not Found
The requested resource could not be found. The most famous HTTP status code on the web.
405
Method Not Allowed
The HTTP method is not supported for this resource. The Allow header lists permitted methods.
408
Request Timeout
Server timed out waiting for the client to send a request. Connection can be reused.
409
Conflict
Request conflicts with the current state of the server — e.g., concurrent modification or duplicate entry.
410
Gone
Resource was permanently removed and won't return. Unlike 404, the condition is expected to be permanent.
413
Payload Too Large
Request body exceeds the server's size limit. Retry-After may indicate when to try again.
418
I'm a Teapot ☕
Any attempt to brew coffee with a teapot should result in this error. RFC 2324 April Fools' joke — now an IETF standard.
422
Unprocessable Entity
Request is well-formed but has semantic errors — e.g., validation failed. Common in REST APIs with JSON body validation.
429
Too Many Requests
Rate limit exceeded. The Retry-After header indicates when the client may try again.
5xx — Server Error
500
Internal Server Error
Generic server error. An unexpected condition was encountered. Check server logs for details.
501
Not Implemented
Server does not recognize or support the request method. Only GET and HEAD are required methods.
502
Bad Gateway
Proxy received an invalid response from an upstream server. Common with nginx/load balancer setups.
503
Service Unavailable
Server temporarily unable to handle requests — overloaded or under maintenance. Retry-After header may be present.
504
Gateway Timeout
Proxy didn't receive a timely response from the upstream server. Indicates backend latency issues.
HTTP Headers
Request Headers
HeaderExample ValueDescription
Acceptapplication/json, text/htmlMedia types the client can process
AuthorizationBearer eyJ0eXAiOiJKV1Q...Credentials for authenticating the request
Cache-Controlno-cache, max-age=3600Caching directives for request/response chain
Content-Typeapplication/json; charset=utf-8Media type of the request body
Hostapi.example.comDomain name of the server (required in HTTP/1.1)
User-AgentMozilla/5.0 (X11; Linux x86_64)Identifies the client software making the request
Refererhttps://example.com/pageURL of the page that linked to this request
Cookiesession=abc123; theme=darkPreviously set cookies sent back to the server
If-Modified-SinceMon, 01 Jan 2024 00:00:00 GMTConditional GET: return resource only if newer
Originhttps://app.example.comOrigin of the cross-site request (used in CORS)
X-Forwarded-For203.0.113.42, 10.0.0.1Original client IP behind proxies/load balancers
Accept-Encodinggzip, deflate, brCompression formats the client understands
Response Headers
HeaderExample ValueDescription
Content-Typetext/html; charset=UTF-8Media type of the response body
Content-Length3428Size of response body in bytes
Content-EncodinggzipEncoding applied to the response body
Set-Cookiesession=xyz; HttpOnly; SecureInstructs client to store a cookie
Cache-Controlpublic, max-age=86400How long and by whom the response may be cached
ETag"33a64df551425fcc55e4d42a148795d9"Identifier for a specific version of the resource
Last-ModifiedWed, 21 Oct 2024 07:28:00 GMTDate the resource was last modified
Locationhttps://example.com/new-pathURL for redirect (3xx) or new resource (201)
WWW-AuthenticateBearer realm="example"Authentication scheme required (sent with 401)
Access-Control-Allow-Originhttps://app.example.comWhich origins are allowed to read the response (CORS)
Strict-Transport-Securitymax-age=31536000; includeSubDomainsForce HTTPS for future requests (HSTS)
X-Frame-OptionsDENYPrevents the page from being embedded in iframes
General / Entity Headers
HeaderExample ValueDescription
Connectionkeep-aliveControls whether the connection stays open after the current transaction
DateTue, 15 Nov 2024 08:12:31 GMTDate and time at which the message was originated
Transfer-EncodingchunkedForm of encoding used to transfer the body; chunked allows streaming
UpgradewebsocketRequests the server switch to a different protocol
Via1.1 proxy.example.comTracks the intermediaries (proxies/gateways) the message passed through
HTTP Version History
HTTP/0.91991 — Tim Berners-Lee, CERN
The "one-liner" protocol. Only GET method, only HTML responses, no headers, no status codes. A single TCP connection per request, closed after the response.
GET onlyNo headersHTML onlyNo status codes
HTTP/1.01996 — RFC 1945
Added HTTP headers, status codes, and content type negotiation. Multiple methods (GET, POST, HEAD). Still one request per TCP connection — each request requires a new connection, causing significant overhead.
Headers addedStatus codesContent-TypePOST/HEAD
HTTP/1.11997 — RFC 2068, updated RFC 7230–7235
The dominant protocol for over a decade. Introduced persistent connections (keep-alive), chunked transfer encoding, virtual hosting (Host header required), content negotiation, and partial content (Range). Still has head-of-line blocking.
Persistent connectionsChunked transferVirtual hostingPipeliningCache control
HTTP/22015 — RFC 7540 (based on SPDY)
Binary protocol (not text-based). Multiplexing solves head-of-line blocking at the application layer — multiple requests/responses over a single connection simultaneously. HPACK header compression reduces overhead. Server push allows proactively sending resources. TLS de facto required.
Binary frames Multiplexing HPACK compression Server Push Stream priority
HTTP/32022 — RFC 9114 (based on QUIC)
Runs over QUIC (UDP-based) instead of TCP, eliminating TCP-level head-of-line blocking entirely. Built-in TLS 1.3, faster connection setup (0-RTT resumption), better performance on lossy networks. Connection migration handles IP address changes (e.g., switching Wi-Fi to mobile).
QUIC/UDP 0-RTT resumption No HOL blocking TLS 1.3 built-in Connection migration
Version Comparison
Feature HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/3
TransportTCPTCPTCPQUIC/UDP
Persistent Connections✗✓✓✓
Multiplexing✗✗✓✓
Header Compression✗✗HPACKQPACK
Server Push✗✗✓✓
Binary Protocol✗✗✓✓
Built-in Encryption✗✗✗✓
0-RTT Resumption✗✗✗✓
HOL BlockingTCPTCPTCP onlyNone
HTTP Security
HTTPS / TLS CRITICAL
Transport Layer Security (TLS) encrypts the HTTP channel. TLS 1.3 (RFC 8446, 2018) is the current standard — 1-RTT handshake, forward secrecy via ephemeral keys, removed weak cipher suites. Always prefer TLS 1.3; disable 1.0 and 1.1.
ssl_protocols TLSv1.2 TLSv1.3; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m;
HSTS — HTTP Strict Transport Security HEADER
Instructs browsers to only connect via HTTPS for a specified duration. Prevents SSL-stripping attacks. Include subdomains and preload for maximum protection.
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
CSP — Content Security Policy HEADER
Restricts the sources from which scripts, styles, images, and other resources can be loaded. The primary defense against XSS attacks. Violations can be reported via report-uri.
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'; img-src 'self' data:; report-uri /csp-report
CORS — Cross-Origin Resource Sharing HEADER
Browser mechanism that controls which origins can access a resource. Preflight OPTIONS requests check permissions. Set Access-Control-Allow-Origin to specific domains, never * with credentials.
Access-Control-Allow-Origin: https://app.example.com Access-Control-Allow-Methods: GET, POST Access-Control-Allow-Headers: Authorization Access-Control-Allow-Credentials: true
SameSite Cookies CSRF DEFENSE
Cookie attribute preventing CSRF by controlling when cookies are sent cross-site. Strict = never cross-site; Lax = safe methods only; None = always (requires Secure). Default is Lax in modern browsers.
Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict; Path=/; Max-Age=86400
X-Frame-Options / CSP frame-ancestors CLICKJACKING
Prevents your page from being embedded in an iframe on another origin — defends against clickjacking attacks. X-Frame-Options is legacy; use CSP frame-ancestors instead which supports allowlists.
X-Frame-Options: DENY # Modern equivalent: Content-Security-Policy: frame-ancestors 'none';
X-Content-Type-Options MIME SNIFF
Prevents browsers from MIME-sniffing a response away from the declared Content-Type. Stops attackers from tricking browsers into treating uploaded files as executable content.
X-Content-Type-Options: nosniff
Certificate Transparency & OCSP Stapling PKI
Certificate Transparency (CT) logs all issued certs in public, auditable logs — browsers require CT for trust. OCSP Stapling allows the server to cache and deliver the certificate revocation status, improving privacy and performance.
ssl_stapling on; ssl_stapling_verify on; resolver 8.8.8.8 valid=300s; # CT enforced by browsers automatically
Permissions-Policy & Referrer-Policy PRIVACY
Permissions-Policy (formerly Feature-Policy) controls access to browser APIs like camera, microphone, geolocation. Referrer-Policy limits how much URL info is sent in the Referer header to third-party sites.
Permissions-Policy: camera=(), microphone=(), geolocation=() Referrer-Policy: strict-origin-when-cross-origin
HTTP — A History of the Web's Protocol
1989
Tim Berners-Lee Proposes the Web. While at CERN, Berners-Lee writes "Information Management: A Proposal" — the document that becomes the World Wide Web. He envisions a hypertext system for sharing documents, built on a simple request/response protocol over TCP/IP.
HTTP/0.91991
The one-liner. A single-line protocol with only GET. No headers, no status codes, no metadata — send a request, receive HTML, connection closes. It could only transfer HTML documents.
GET only No headers HTML only No status codes
HTTP/1.0RFC 1945 · 1996
Adds POST and HEAD methods, response status codes, HTTP headers, and support for content types beyond HTML. Each request still opens a new TCP connection — expensive at scale.
Status codes Headers POST / HEAD Content-Type
HTTP/1.1RFC 2616 · 1997
The landmark version that powered the web for over 15 years. Introduces persistent connections (keep-alive), chunked transfer encoding, virtual hosting via Host header, cache control, and content negotiation. Still widely deployed today.
Keep-Alive Virtual Hosting Chunked Transfer Cache-Control Pipelining
REST2000
Roy Fielding's doctoral dissertation formalizes REST as an architectural style built on HTTP semantics. GET, POST, PUT, DELETE map to CRUD operations. The web API era begins, and HTTP evolves from a document transfer protocol to an application layer.
Stateless Resource-Oriented Uniform Interface
HTTP/2RFC 7540 · 2015
Based on Google's SPDY protocol. Introduces binary framing (replacing plain text), multiplexing (multiple requests over one TCP connection), header compression (HPACK), and server push. Dramatically reduces latency for modern web pages loading dozens of assets.
Binary Framing Multiplexing HPACK Compression Server Push Stream Priority
HTTP/3RFC 9114 · 2022
HTTP/3 replaces TCP with QUIC (built on UDP). Eliminates TCP head-of-line blocking entirely, reduces connection setup to 0-RTT for returning clients, and makes the protocol resilient to packet loss. Now used by ~30% of the web.
QUIC / UDP 0-RTT Resumption No HOL Blocking Connection Migration Built-in TLS 1.3
Today
HTTP underpins web browsing, APIs, microservices, IoT, and inter-datacenter communication. WebSockets, Server-Sent Events, and WebTransport extend HTTP for real-time use cases. HTTPS (HTTP over TLS) is the mandatory default for all production traffic on the modern web.
HTTPS Default WebSockets WebTransport gRPC Server-Sent Events