HTTP Cheatsheet
A thorough, student-friendly guide to HTTP: requests, responses, methods, headers, caching, cookies, security headers, HTTP versions, and a complete list of status codes with clear explanations.
What is HTTP?
HTTP (HyperText Transfer Protocol) is the protocol used by web browsers and servers to communicate. It defines how requests are sent, how responses look, and the rules for resources on the web.
Think of HTTP as a language both browser and server speak: browser asks (requests), server answers (responses).
HTTP Request Structure
A request contains a method, URL (path), HTTP version, headers, and an optional body.
GET /path/resource?id=10 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: application/json
Accept-Language: en-US
<optional body for POST/PUT>
- Method: what you want to do (GET, POST, etc.).
- URL / Path: resource you want from the server.
- Headers: metadata (content type, auth tokens, caching hints).
- Body: data sent with some methods (POST, PUT, PATCH).
HTTP Response Structure
A response has a status line (status code + reason), headers, and a body (often HTML, JSON, images, etc.).
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 45
Cache-Control: max-age=3600
{ "id": 10, "name": "Alice", "active": true }
The status code helps the client know what happened (success, redirect, client error, server error).
HTTP Methods (Verbs)
Methods indicate the desired action. Here are the most common ones and how to think about them.
GET
Retrieve a representation of a resource. Should be safe (no side effects) and idempotent (multiple identical requests have same effect).
GET /posts/1
POST
Create a new resource or perform a processing action. Not idempotent by default (multiple POSTs may create multiple resources).
POST /posts
Content-Type: application/json
{ "title": "New Post", "body": "Hello" }
PUT
Replace an entire resource at the given URL. Typically idempotent: repeating the same PUT won't change result beyond first application.
PUT /posts/1
Content-Type: application/json
{ "title": "Updated", "body": "New body" }
PATCH
Partially update a resource. Often used when you only want to change a few fields.
PATCH /posts/1
Content-Type: application/json
{ "title": "Small edit" }
DELETE
Remove a resource. Usually idempotent: deleting an already-removed resource typically returns 404 or 204 depending on design.
DELETE /posts/1
HEAD
Same as GET but server returns only headers (no body). Useful for checking metadata or caching without downloading content.
OPTIONS
Ask the server which methods and headers are supported for a resource. Common with CORS preflight checks.
Common HTTP Headers
Headers transmit metadata. There are request headers, response headers, and entity headers.
Important Request Headers
Host
: which host the client wants (domain + optional port).User-Agent
: identifies the client (browser or app).Accept
: which response content types are acceptable (e.g.application/json
).Accept-Language
: preferred languages.Authorization
: credentials (e.g.Bearer <token>
).Content-Type
: type of request body (e.g.application/json
).Content-Length
: size of the request body in bytes.If-Modified-Since
/If-None-Match
: conditional requests for caching.
Important Response Headers
Content-Type
: type of response body (e.g.text/html
,application/json
).Content-Length
: response body size.Cache-Control
: caching rules for clients and proxies.ETag
: an identifier for a version of the resource used by caches.Set-Cookie
: ask the client to store cookies.Location
: new URL for redirections (301/302/201).WWW-Authenticate
: used with 401 Unauthorized to indicate needed auth scheme.
Example: JSON POST request
POST /api/items HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer abc123
{ "name": "Widget", "qty": 10 }
Caching
Caching improves performance by storing copies of resources. HTTP provides directives to control caching behavior for browsers and proxies.
Cache-Control
Most important header for caching. Example values:
Cache-Control: max-age=3600, public
Cache-Control: no-cache
Cache-Control: no-store
max-age
: seconds cached.public
/private
: whether proxies can cache.no-cache
: must revalidate with server before using cached copy.no-store
: do not store at all.
ETag & Conditional Requests
ETag is a fingerprint for a resource. Clients can ask the server if content changed using If-None-Match
. If not changed, server returns 304 Not Modified
(no body), saving bandwidth.
ETag: "abc123"
If-None-Match: "abc123"
--> 304 Not Modified
Security Headers
Use these headers to harden your web app against common attacks.
Content-Security-Policy (CSP)
Controls which sources are allowed to load scripts, styles, images, etc. Helps reduce XSS attacks.
Content-Security-Policy: default-src 'self'; img-src 'self' https://images.example.com;
Strict-Transport-Security (HSTS)
Force browsers to use HTTPS. Set long durations in production.
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Content-Type-Options
Prevents MIME-type sniffing.
X-Content-Type-Options: nosniff
Referrer-Policy
Controls how much referrer information is sent with requests.
Referrer-Policy: no-referrer-when-downgrade
X-Frame-Options
Protects against clickjacking by controlling if the page can be framed.
X-Frame-Options: DENY
HTTP Versions (1.1, 2, 3)
HTTP evolved to improve speed and reliability:
- HTTP/1.1 — persistent connections (keep-alive), chunked responses, widely supported.
- HTTP/2 — multiplexing (multiple requests/responses on single connection), header compression, server push. Improves latency.
- HTTP/3 — runs over QUIC (UDP-based), reduces connection/setup latency and improves reliability on lossy networks.
HTTP Status Codes (Grouped)
Status codes are grouped by class. Each code tells the client what happened.
1xx — Informational
Temporary responses to indicate progress.
2xx — Success
The request was received, understood, and accepted.
Location
header pointing to the new resource.3xx — Redirection
Further action needed to fulfill the request (usually a redirect).
4xx — Client Errors
The request contains bad syntax or cannot be fulfilled by the server.
WWW-Authenticate
header to indicate auth method.Allow
header listing allowed methods.Content-Length
header.Retry-After
header when appropriate.5xx — Server Errors
Server failed to fulfill a valid request. These are server-side issues.
Practical Examples & Tips
Using Fetch (browser)
fetch('/api/items', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ name: 'Widget' })
})
.then(r => {
if (!r.ok) throw new Error('Request failed: ' + r.status);
return r.json();
})
.then(data => console.log(data));
cURL Examples
# GET
curl -i https://api.example.com/posts/1
# POST JSON
curl -i -X POST https://api.example.com/posts \
-H "Content-Type: application/json" \
-d '{"title":"Hi","body":"Hello"}'
Handling 429 Rate Limits
Respect Retry-After
header and implement exponential backoff.
Design tip: API Versioning
Include a version in the URL or in headers (e.g., /v1/users
) so you can change the API without breaking clients.
How to use this page
- Read the request/response structure to understand the pieces of HTTP messages.
- Practice common methods (GET/POST/PUT/PATCH/DELETE) with cURL or fetch.
- Learn essential headers (Content-Type, Authorization, Cache-Control, ETag).
- Use the status codes list to understand server responses and design API behavior.
🚀 Explore More Free Developer Tools
Don’t stop here! Supercharge your workflow with our other powerful converters & formatters.
📚 Docker Cheatsheet
Docker Cheatsheet
📚 MongoDB Cheatsheet
MongoDB Cheatsheet
📚 Git Cheatsheet
Git Cheatsheet
💡 New tools are added regularly — bookmark DevUtilsX and stay ahead!
Want to support my work?
Buy me a coffee