HTTP
HTTP is a semantic application protocol, not merely JSON over TCP. Methods, status codes, representation metadata, conditional requests, caches, proxies, authentication, and protocol versions all affect correctness and performance. Senior candidates preserve HTTP semantics across retries and intermediaries, understand HTTP/1.1, HTTP/2, and HTTP/3 trade-offs, and design observable deadline and overload behavior.
How to use this chapter
- Read the mental model and mechanics without taking notes.
- Close the page and explain the topic aloud in five minutes.
- Work the quantitative example on paper.
- Answer the question ladder without revealing the answer signals.
- Complete one design drill and score yourself with the senior checklist.
Learning objectives
- Explain HTTP messages, resources, representations, methods, status classes, and headers.
- Use safety, idempotency, conditional requests, and preconditions to make retries correct.
- Reason about HTTP caching, validation, content negotiation, range requests, and compression.
- Compare HTTP/1.1, HTTP/2, and HTTP/3 at the right abstraction level.
- Design timeouts, redirects, authentication, CORS, rate limits, and proxy behavior.
- Diagnose request smuggling, retry amplification, connection saturation, and tail latency at senior level.
Mental model
HTTP separates semantics—what a request means—from framing/transport—how messages cross a connection. The same GET semantics can run over HTTP/1.1, HTTP/2, or HTTP/3. Intermediaries may cache, transform, route, retry, authenticate, or reject requests, so correctness cannot depend on a direct client-to-origin connection unless the protocol explicitly establishes one.
Core mechanics
Resources, representations, and messages
A URI identifies a resource; a representation is a current or intended state encoded in a media type. Requests and responses carry method/status, fields, and optional content. The protocol does not require resources to map one-to-one to database rows.
Content type describes the representation format. Content negotiation can use Accept, language, encoding, and related fields, but excessive variants complicate caches through Vary. Use explicit versioned media types only when their benefit exceeds client and cache complexity.
Methods: safety and idempotency
Safe methods are intended to be read-only from the user’s perspective; they can still produce logs or billing. Idempotent methods can be repeated with the same intended effect, which makes transport retries safer. GET, HEAD, PUT, and DELETE are defined as idempotent; POST is not inherently idempotent, but an API can make a specific POST retryable with an idempotency key.
Method semantics matter more than CRUD slogans. PUT usually replaces the selected resource representation; PATCH applies partial changes whose format defines semantics. A DELETE response does not imply every derived cache/search copy vanished instantly unless the API promises that.
Status codes and error bodies
Use status classes consistently: 2xx success, 3xx redirection, 4xx client-side/request conditions, and 5xx server failure. Distinguish authentication failure, authorization denial, conflict, precondition failure, rate limiting, and temporary unavailability. A machine-readable problem format should include stable error codes, human detail, field violations, retry guidance, and correlation ID without leaking secrets.
Do not return 200 with an error payload for ordinary failures; it breaks intermediaries, metrics, and client libraries. For asynchronous work, 202 can acknowledge acceptance while a status resource reports completion.
Conditional requests and optimistic concurrency
Validators such as entity tags and modification times support cache validation and update preconditions. If-None-Match can produce 304 for an unchanged representation. If-Match can ensure an update only applies to the version the client observed, preventing lost updates.
ETags may be strong or weak depending on equivalence requirements. Do not derive them from unstable serialization accidentally. Preconditions are often better than distributed locks for user-facing edits because conflicts are explicit and retryable.
Caching and freshness
HTTP caches store responses according to method/status and cache-control rules. Cache-Control can express freshness, revalidation, shared-cache restrictions, stale behavior, and no-store requirements. Age, validators, and cache-status information help debugging.
Personalized content is not automatically uncacheable, but cache keys and authorization/privacy must be correct. Vary: * effectively prevents reuse; varying on high-cardinality headers can destroy hit ratio. Cache invalidation should use versioned URLs for immutable assets and targeted purge/revalidation for mutable content.
Protocol versions
HTTP/1.1 commonly reuses persistent TCP connections but has textual framing and limited request concurrency per connection in practice. HTTP/2 uses binary framing, header compression, and multiplexed streams over a TCP connection. It reduces connection proliferation but shares TCP-level loss and connection-level flow control.
HTTP/3 maps HTTP semantics over QUIC. Independent transport streams reduce cross-stream head-of-line blocking after packet loss and connection setup can improve, especially on high-RTT or changing networks. CPU, UDP path support, and implementation maturity must be measured. Clients and servers often negotiate versions and retain fallback.
Streaming, ranges, and compression
HTTP supports streaming request/response bodies, chunked or framed transfer depending on version, range requests for partial retrieval, and compression. Streaming reduces peak memory and time-to-first-byte but requires backpressure and disconnect handling. Range support enables resume and media seeking, but validators must ensure chunks belong to the same object version.
Compression saves bandwidth but costs CPU and can create security risks when secrets and attacker-controlled text share compression context. Avoid compressing already compressed formats and choose algorithms by payload size, client support, and latency/cost profile.
Intermediaries, security, and browser behavior
Forward proxies act for clients; reverse proxies act in front of servers. Hop-by-hop fields apply only to one connection and must not be forwarded as end-to-end metadata. Inconsistent request parsing between intermediaries can cause request smuggling, so normalize framing and keep implementations patched.
Browser APIs add same-origin and CORS rules; CORS is a browser permission mechanism, not server-side authentication. Cookies need secure attributes and CSRF defenses where ambient credentials are used. Bearer tokens require TLS and careful audience/scope/lifetime handling.
Decision table
| Decision | Prefer the first option when… | Prefer the second option when… | Senior caveat |
|---|---|---|---|
| GET vs POST for query | The operation is safe, cacheable, bookmarkable, and parameters fit URI limits/privacy. | The query is large/sensitive or has non-safe semantics. | A POST query is not automatically cacheable across generic intermediaries and retries need explicit semantics. |
| PUT vs PATCH | Client supplies a complete replacement and can safely retry. | Partial mutation or domain operation is required. | Define omitted fields, null, array merge, validation, and idempotency precisely. |
| ETag precondition vs lock | Conflicts can be detected at commit and resolved by clients. | Exclusive long-running access is a real product requirement. | Locks need leases/fencing and failure recovery; ETags expose conflicts without server-held sessions. |
| HTTP/2 vs HTTP/3 | Mature TCP path and infrastructure are sufficient. | Loss/RTT/mobility measurements show QUIC benefit. | Support negotiation/fallback and compare CPU plus operational visibility. |
| Buffer vs stream body | Payload is small and atomic validation is simple. | Large/continuous payloads require low memory and early processing. | Streaming complicates retries, partial failure, checksums, and transaction boundaries. |
| Redirect vs proxy | Client can learn/use the destination and extra round trip is acceptable. | Destination must be hidden or server must preserve one endpoint/session. | Redirect semantics differ by status/method; signed URLs and auth leakage need care. |
Quantitative reasoning
Failure modes and production signals
| Failure mode | What users see | Likely cause | Mitigation / design response | Useful signals |
|---|---|---|---|---|
| Retry duplicate | Duplicate order/payment/action | Client/proxy retries non-idempotent request after timeout | Idempotency key, atomic dedupe/commit, durable response lookup | Retry attempts, duplicate-key hits, timeout-after-commit audits |
| Cache privacy leak | One user receives another user’s content | Incorrect cache key or shared-cache directives | Private/no-store where needed, include authorization dimensions, test variants | Cache key logs, user mismatch canaries, cache-status |
| Connection saturation | Queueing and 503 despite backend CPU headroom | Pool/stream/connection limits | Tune bounded pools, multiple connections, backpressure, expose queue wait | Active streams, pool pending, connection count, wait time |
| Request smuggling | Cross-user request confusion or security incident | Frontend/backend parse disagreement | Single framing, reject ambiguous requests, patch/normalize proxies | Malformed request rejects, proxy discrepancies, security alerts |
| Compression CPU spike | High CPU and latency on large responses | Dynamic compression at high level | Precompress/cache, choose lower level/algorithm, disable for small/already compressed | Compression time, ratio, CPU per byte |
| Timeout mismatch | Upstream completes after caller gave up; wasted work | Nested timeouts not derived from deadline | Propagate deadlines/cancel, leave response margin, cap retries | Cancelled work, remaining budget, late responses |
Senior-level lenses
Idempotency is end-to-end
A method label alone is insufficient. The client, gateway, service, database, and side effects must agree on a stable operation identity. Store the dedupe record atomically with the result or state transition, define key scope/expiry, and return the original result on a replay.
Caching is part of the contract
Specify freshness, staleness, invalidation, variants, authorization, and failure behavior. no-cache means revalidate before reuse, not “never store”; no-store forbids storage. Senior candidates distinguish browser, shared proxy/CDN, and application caches.
Intermediaries alter failure semantics
Gateways may retry, buffer, transform, cap body size, or close idle streams. Document proxy timeouts and retry policies, pass request IDs and deadlines, and ensure only one layer owns automatic retries for each failure class.
Backpressure must cross HTTP layers
A streaming handler should stop reading when downstream storage is saturated and stop writing when the client is slow. Otherwise proxy and application buffers hide pressure until memory fails. Bound buffers and define whether to pause, reject, or spill to durable storage.
Protocol selection is empirical
HTTP/3 can improve high-loss/high-RTT client paths but may increase CPU or face blocked UDP. Segment experiments by network type, connection reuse, payload, and device. Retain fallback and avoid attributing application p99 to protocol alone.
Cancellation is not rollback
A client disconnect or deadline can cancel unnecessary work, but a transaction may already be committed or an external side effect may not support cancellation. Design operation status and idempotent retry so the client can discover the result.
Interview question ladder
What is the difference between safe and idempotent HTTP methods?
Show strong-answer signals
Safe means intended not to change resource state; idempotent means repeated identical requests have the same intended effect. Give GET/PUT/DELETE/POST examples.
What do 304 and 412 mean in conditional requests?
Show strong-answer signals
304 Not Modified satisfies a cache validator without body; 412 Precondition Failed means an update/read precondition such as If-Match was false.
What is the difference between 401 and 403?
Show strong-answer signals
401 indicates missing/invalid authentication challenge context; 403 means request understood but not authorized, subject to information-disclosure policy.
How would you make a POST payment request safely retryable?
Show strong-answer signals
Client-generated idempotency key scoped to operation/account, atomic dedupe plus payment state, persisted original response, request fingerprint, expiry, and conflict behavior.
Explain HTTP cache validation with ETag.
Show strong-answer signals
Cache stores response+ETag, sends If-None-Match when stale, origin returns 304 or new representation. Mention strong/weak validators and Vary.
Compare HTTP/1.1 and HTTP/2 for many small concurrent requests.
Show strong-answer signals
HTTP/2 multiplexing and header compression reduce connection count/HTTP-level blocking, but shares TCP loss/flow control and has stream/concurrency limits.
Design deadlines and retries for an API gateway calling three services.
Show strong-answer signals
End-to-end deadline propagation, per-hop budgets, only transient/idempotent retries, jitter and budget, no nested amplification, cancellation, 429/503 guidance, and tracing of attempts.
A CDN cached authenticated JSON and leaked it. What controls and tests prevent recurrence?
Show strong-answer signals
Explicit private/no-store or correct shared cache key; strip untrusted headers; Vary carefully; token/cookie behavior; cache-status; synthetic users; config review; purge incident plan.
How do you upload a 50 GiB file over HTTP reliably?
Show strong-answer signals
Create upload session, chunk/range or multipart parts, checksums, parallel bounded uploads, idempotent part IDs, resume/list parts, final atomic commit/version, expiry, auth, and size quotas.
When would a 202 response be preferable to holding the connection open?
Show strong-answer signals
Long/variable work, external dependencies, burst buffering. Need durable acceptance, status resource/webhook, idempotency, cancellation, retry/expiry, and user SLO.
Design a multi-hop HTTP retry policy that remains safe under partial regional failure.
Show strong-answer signals
Single retry owner or coordinated attempt metadata, end-to-end deadline, idempotency, per-region failover, retry budgets, circuit/outlier signals, overload-aware no-retry, and accounting for late commits.
Migrate a public API from HTTP/1.1 to HTTP/3 without harming long-tail clients.
Show strong-answer signals
Alt-Svc/negotiation, telemetry by network/device, UDP reachability, fallback, canary cohorts, CPU capacity, connection migration, security/proxy compatibility, and rollback.
Design drills
Specify HTTP endpoints and state transitions for creating an order, authorizing payment, polling status, cancelling, and retrieving the final receipt. Include idempotency, ETags, errors, and retry rules.
What the interviewer is testing
Correct semantics under timeout and concurrent update, not only endpoint naming.
Design HTTP delivery for multi-gigabyte videos via CDN. Include ranges, validators, immutable versions, cache headers, signed authorization, compression choices, and origin protection.
What the interviewer is testing
HTTP as a caching/streaming protocol and interaction with CDN/security.
Users on lossy mobile networks see worse p99 after moving from several HTTP/1.1 connections to one HTTP/2 connection. Form hypotheses, measurements, and mitigations including HTTP/3.
What the interviewer is testing
Layered head-of-line reasoning, connection pooling, loss segmentation, and evidence-based protocol choice.
Common weak answers and how to improve them
“POST is always non-idempotent.”
Show the stronger answer
The method is not defined as idempotent, but an operation can implement idempotency with a key and atomic result storage.
“Cache-Control: no-cache disables caching.”
Show the stronger answer
It permits storage but requires validation before reuse; use no-store to prohibit storage.
“HTTP/2 removes head-of-line blocking.”
Show the stronger answer
It removes HTTP/1.x request serialization but shares TCP loss recovery across streams.
“Return 500 for any error.”
Show the stronger answer
Use stable 4xx/5xx semantics, machine-readable codes, retryability, and correlation.
“If the client timed out, the server rolled back.”
Show the stronger answer
The operation may have committed; expose status and idempotent retry.