Headers: types and roles
- Request headers: e.g., Authorization, Accept, User-Agent; inform server about credentials, preferences, and client capabilities.
- General headers: apply to both directions; e.g., Date, Cache-Control, Connection.
- Representation headers: describe payload; e.g., Content-Type, Content-Length, Content-Encoding, ETag.
- Security headers: HSTS, CSP, X-Frame-Options, X-Content-Type-Options, cookie flags like HttpOnly/Secure.
Header principles
- Extensibility: headers can be added or customised without changing HTTP semantics, enabling evolution (security, caching, features) via metadata.
- “Remote control”: clients and servers can steer behaviour via headers (e.g., Accept for content negotiation, Cache-Control for caching, Authorisation for auth).
Methods and semantics
- GET: fetch representation; no server-side modification expected; safe and idempotent.
- POST: create or trigger non-idempotent operations; request body carries data.
- PUT: full replacement of a resource; idempotent by definition.
- PATCH: partial update; not necessarily idempotent unless designed so.
- DELETE: remove a resource; idempotent in effect since repeated deletes yield the same result.
- OPTIONS: discovery of capabilities, especially used by browsers for CORS preflight.
Idempotency overview
| Method | Idempotent? | Notes |
|---|---|---|
| GET | Yes | Repeating reads should not change state |
| POST | No | Typically creates new resources or triggers side effects |
| PUT | Yes | Complete replacement yields same final state on repeats |
| PATCH | Usually No | Semantics vary; partial updates may not be idempotent |
| DELETE | Yes | Deleting again keeps state unchanged (resource remains absent) |
CORS basics
- Browsers enforce the same-origin policy, restricting cross-origin requests unless the server opts in via CORS headers.
- Two flows: simple requests (GET/POST/HEAD with simple headers/content types) and preflight (OPTIONS) when using non-simple methods, custom headers, or JSON content types.
Simple request flow
- Browser includes Origin header and sends the request; server responds with Access-Control-Allow-Origin to allow the response to be exposed.
- If ACAO is missing or mismatched, the browser blocks the response even if the server computed it correctly.
Preflight (OPTIONS) flow
- Browser sends OPTIONS with Access-Control-Request-Method and Access-Control-Request-Headers to query server capabilities.
- Server responds with 204 No Content plus Access-Control-Allow-Origin/Methods/Headers and optional Access-Control-Max-Age to cache the preflight result.
https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request
Status codes: categories
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status
- 1xx informational: e.g., 100 Continue for large uploads; 101 Switching Protocols (e.g., WebSocket upgrades).
- 2xx success: 200 OK, 201 Created, 204 No Content (often for OPTIONS/DELETE).
- 3xx redirection: 301 Moved Permanently, 302 Temporary Redirect, 304 Not Modified for caching.
- 4xx client errors: 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 405 Method Not Allowed, 409 Conflict, 429 Too Many Requests.
- 5xx server errors: 500 Internal Server Error, 501 Not Implemented, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout.
Caching essentials
https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching
- Validators like ETag enable conditional GETs; if unchanged, server returns 304 Not Modified to save bandwidth. (Its is a hash which is computed from the response by the server and sent to the client)
- Cache-Control (e.g., max-age) instructs how long responses can be reused; servers and clients leverage this to reduce load.
In the response of the first request you will receive these two headers
In the next request and response these header will be send and the following status code will be received
This is good but in production setting these things should be implemented by the server explicitly and if the server misses to update the eTag then the client will continue to use the cached version so its better to use a client side caching like react query etc.
Compression
- Response compression with gzip/deflate/br reduces payload size; indicated via Content-Encoding and requested via Accept-Encoding.
- Compression reduces network transfer time but must be configured safely to avoid issues like compression-based attacks in sensitive contexts.
Persistent connections
- HTTP/1.1 introduced keep-alive by default, allowing multiple requests/responses per TCP connection to reduce handshake overhead.
- HTTP/2 and HTTP/3 multiplex streams over a single connection, improving concurrency and avoiding head-of-line blocking at the application layer.
Multipart and chunked
- Multipart enables file uploads and mixed content in a single request with boundaries separating parts.
- Chunked transfer encoding streams dynamically generated content without a known Content-Length, sending data in chunks.
TLS and HTTPS
- HTTPS = HTTP over TLS, adding encryption, integrity, and authentication via certificates; same HTTP semantics with security benefits.
- TLS handshakes and certificates are part of the security layer; in HTTP/3, TLS is integrated into QUIC rather than layered on top.
Demo takeaways
- In the CORS demo, removing Access-Control-Allow-Origin made the browser block the response despite a server reply, illustrating client-enforced policy.
- The preflight example showed OPTIONS → 204 with ACAO/ACAM/ACAH → actual request flow, with Access-Control-Max-Age controlling preflight caching.
- The status code demo walked through 200/201/400/401/403/404 and explained when the client or server should emit each.
Practical guidance
- Prefer PATCH for partial updates and PUT only when replacing the entire resource to preserve semantic clarity.
- Implement clear, standard status codes and leverage ETag/Cache-Control for efficient caching and conditional requests.
- For cross-origin SPAs, configure CORS preflight responses correctly and set Access-Control-Max-Age to reduce preflight overhead.
Time-indexed outline (from ToC)
- HTTP intro, evolution, messages, and headers.
- Methods, idempotency, OPTIONS, and full CORS workflow with demos.
- Status codes with demos, caching, content negotiation, compression, keep-alive, multipart/chunked, and HTTPS/TLS.