HTTP, networking, and web boundaries

Status: Complete. Last reviewed 2026-08-28.

An HTTP request is an application message carried through name resolution, transport security, connections, intermediaries, and an application runtime. Correct diagnosis separates those layers. A timeout, cache leak, or malformed character is not explained by saying “the API was slow.”

Trace an HTTPS request

The client parses a URL into scheme, authority, path, query, and fragment. The fragment is client-side and is not sent in the HTTP request. It resolves the hostname, usually consulting process, operating-system, recursive-resolver, and authoritative DNS caches. DNS records and TTLs influence when clients observe changes; caches, negative answers, load balancers, and long-lived connections mean a record update is not instantaneous traffic migration.

The client reaches an address over a transport. HTTP/1.1 and HTTP/2 commonly use TCP; HTTPS then performs TLS authentication and key agreement. The client must validate the certificate chain, hostname, validity, and trust policy. TLS protects confidentiality and integrity in transit between its endpoints. It does not validate application input, prevent an authorized peer from sending malicious data, or protect plaintext after termination.

HTTP/1.1 carries messages over connections and has ordering/connection-reuse constraints. HTTP/2 multiplexes streams over one TCP connection and compresses headers; loss at TCP still affects the connection. HTTP/3 maps HTTP semantics onto QUIC over UDP, with independent streams and integrated TLS. These versions change transport behavior and operational evidence, not the meanings of methods, fields, status codes, or cache directives.

A CDN, reverse proxy, ingress, load balancer, service mesh, or web server may terminate TLS, select an upstream, rewrite fields, buffer bodies, retry, compress, cache, or impose size/time limits. The application sees the effective request produced by that chain, not necessarily the original socket. Trust forwarding fields such as Forwarded or X-Forwarded-* only from configured proxies; otherwise a client can spoof scheme or address decisions.

HTTP message semantics

HTTP methods, status codes, representation metadata, and fields form a shared protocol contract. Safe methods are intended for retrieval and should not request state change. Idempotent methods have the same intended effect when the same request is repeated, although each attempt can produce logs or other incidental effects. GET and HEAD are safe and idempotent; PUT and DELETE are idempotent but unsafe; POST is not idempotent by definition. Applications can add deduplication semantics to commands, but that does not redefine the method globally.

Requests and responses can stream. Intermediaries may buffer them, so “the controller streams” does not prove the client receives incremental bytes. Body size limits, decompression, transfer coding, content length, and aborted connections need consistent policy at every hop. A proxy timeout shorter than an application timeout can produce a gateway error while the upstream continues expensive work.

Connection reuse avoids handshakes, but stale connections, DNS changes, idle timeouts, and pool exhaustion create distinct failures. Timeouts should separate connection establishment, TLS, first byte, per-read inactivity, and total deadline where the client supports them. Retrying at proxies, clients, SDKs, and application code simultaneously can multiply traffic and repeat unsafe effects.

Caching is a distributed policy

HTTP caches may exist in browsers, shared proxies, CDNs, and gateways. Cache-Control expresses freshness and reuse rules. max-age governs freshness; s-maxage can specialize shared caches; no-store requests no storage; no-cache allows storage but requires successful validation before reuse. These names are commonly confused.

Validators such as ETag and Last-Modified enable conditional requests. A client can send If-None-Match or If-Modified-Since; a valid unchanged representation can return 304 without a response body. Validators describe a selected representation, so generation and comparison must match content encoding and variant policy.

Vary tells caches which request fields selected a representation. It is not arbitrary application-key configuration. If a response varies by origin, language, encoding, authorization, tenant, currency, or experiment and the cache key omits that dimension, one user can receive another variant. Private authenticated responses should not enter a shared cache without an explicit, reviewed policy. Cache invalidation, purge propagation, stale-on-error behavior, and origin shielding are operational parts of correctness.

Cookies, sessions, origins, and browsers

A cookie is client-held state attached to matching requests according to domain, path, security, SameSite, and expiry rules. A server-side session commonly stores data under an opaque identifier carried in a cookie. Secure restricts cookie transmission to secure contexts; HttpOnly prevents ordinary script access; SameSite constrains some cross-site attachment. These reduce risk but do not make session rotation, expiry, revocation, or authorization unnecessary.

An origin is scheme, host, and port. The same-origin policy restricts browser script access. CORS lets a server declare which cross-origin browser scripts may read or make certain requests; preflight checks method and field permission. CORS is not authentication, does not constrain non-browser clients, and does not by itself prevent a state-changing request.

CSRF exploits ambient credentials such as cookies: another site causes a browser to send an authenticated request. Defenses include unpredictable request tokens, suitable SameSite policy, and origin checks where appropriate. XSS executes attacker-controlled script in the trusted origin and can act with the user’s authority, so it can defeat many CSRF assumptions. Keep these threat models separate.

Time is an instant plus intent

An instant is a point on a timeline; an offset is a difference from UTC; a time zone is a rule set whose offsets change historically and politically. Store event instants in an unambiguous representation, commonly UTC, but preserve the IANA zone and local calendar intent when the rule is “09:00 Europe/Madrid every weekday.” Converting that rule once to UTC loses daylight-saving behavior.

Timestamps from different machines require synchronized clocks for useful ordering, but wall clocks can jump. Durations and deadlines within a process should use monotonic clocks where available. Distributed timestamps are evidence, not a total causal order. Define precision, inclusivity, and serialization; a date-only birthday is not a midnight instant, and an end date is not self-evidently inclusive.

Text, bytes, and representations

Unicode assigns code points; encodings such as UTF-8 map them to bytes; grapheme clusters approximate user-perceived characters. Byte length, code-point count, and displayed-character count differ. Truncating bytes can create invalid UTF-8, while truncating code points can split a visible emoji or combining sequence. Normalize only when the domain needs equivalence and choose a normalization form deliberately.

HTTP representation fields describe media type and content coding. A JSON body should use the protocol’s Unicode/encoding rules, but JSON itself does not define application schemas or universal numeric precision. Large integer identifiers can lose precision in some consumers, so strings are often safer for identifiers. Binary floating point is unsuitable for exact decimal money; use integer minor units only when currency exponent and range are modeled, or a decimal representation with explicit rounding.

URL components have distinct encoding rules. Percent encoding bytes, form encoding, path segments, and query parameters are not interchangeable. Decode at the owning boundary, avoid double decoding, and do not concatenate untrusted path or redirect components without validation.

Failure diagnosis by layer

Name resolution: inspect resolver answers, TTLs, negative caching, address families, and whether existing connections bypass new DNS.
Connection/TLS: separate connect refusal/timeout, certificate validation, handshake negotiation, and idle connection reuse.
Proxy: correlate request IDs across hops; compare size, buffer, retry, and timeout policies and effective forwarded fields.
Origin: measure queue wait, application spans, dependency calls, and time after the proxy has abandoned the response.
Cache: record age, cache status, validator, variant key, and which layer served the response.
Representation: preserve raw bytes/content type at the failing edge and test round trips with non-ASCII, large identifiers, and boundary dates.

Prefer an end-to-end trace with hop timings over isolated “works locally” checks. Packet capture can answer transport questions; proxy access logs answer routing/cache questions; application traces answer origin work. Use the smallest layer that can prove or disprove the hypothesis.

Current and legacy context

Current: HTTP semantics are defined by RFC 9110, caching by RFC 9111, HTTP/2 by RFC 9113, and HTTP/3 by RFC 9114.
Common: Deployments mix protocol versions across client, edge, and upstream hops; the edge may speak HTTP/3 while the application receives HTTP/1.1.
Legacy: Obsolete date formats, non-UTF-8 data, untrusted proxy headers, and HTTP/1.0-era cache assumptions still appear. Preserve compatibility only with an explicit boundary and tests.