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.
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.