HTTP

Software Engineering / 16 Sep 2026 / 7 min read

HTTP Stale-While-Revalidate Moves Cache Refresh Off the Request Path

A cache can return an expired stored response immediately and start validation in parallel when stale-while-revalidate permits that reuse. The request that encounters the stale entry therefore does not have to inherit origin validation latency, but it can receive representation data older than the normal freshness lifetime. This is a deliberate shift in the cache contract. Freshness still expires at the configured boundary. The extension adds a separate interval in which stale reuse is permitted while validation proceeds, so response age and request latency become partially decoupled.

Software Engineering HTTP

Cybersecurity / 16 Sep 2026 / 9 min read

HTTP Request Smuggling Starts When Intermediaries Disagree on Message Boundaries

A reverse proxy accepts an HTTP/1.1 request, decides where its body ends, and forwards traffic to an application server over a persistent connection. If the application server reaches a different boundary from the same framing information, the two components stop agreeing about which bytes belong to which request. Bytes treated as body data by one component can become the start of a new request for the other. That disagreement is the core condition behind HTTP request smuggling. The defect is not simply a malformed header, a proxy, or connection reuse in isolation. It is a parser differential across a chain in which multiple recipients interpret request framing and at least one connection carries subsequent traffic.

Cybersecurity HTTP

Cybersecurity / 16 Sep 2026 / 8 min read

HTTP Request Framing Desynchronization Turns Parser Differences Into a Proxy Boundary Failure

HTTP Request Framing Desynchronization Turns Parser Differences Into a Proxy Boundary Failure A reverse proxy can validate an HTTP request, forward it to an origin, and still leave the origin processing a different request sequence from the one the proxy approved. The failure is not caused by encryption loss or a missing authorization check. It appears when two recipients consume the same connection bytes with different rules for deciding where one message ends and the next begins.

Cybersecurity HTTP

Software Engineering / 16 Sep 2026 / 8 min read

HTTP If-Range Couples Partial Retrieval to Representation Identity

A client that has only part of an HTTP representation faces a consistency problem when it asks for the missing bytes later. Byte offsets are meaningful only against the representation whose bytes established those offsets. If the selected representation changes between requests, combining an old prefix with a new suffix can produce data that no server ever emitted. If-Range attaches representation identity to that partial-retrieval boundary. When its validator matches, the server can process the accompanying Range field. When it does not match, the server ignores Range and sends the complete selected representation through the normal successful response path instead of returning a failed-precondition response.

Software Engineering HTTP

Software Engineering / 16 Sep 2026 / 8 min read

HTTP If-Match Turns Representation State Into a Write Precondition

An HTTP origin can refuse a PUT or DELETE before applying it when the request carries If-Match and the selected representation no longer has an accepted entity tag. The condition converts a representation validator into a write precondition: a client can say that a mutation is valid only against state matching a version it previously observed. This mechanism addresses a specific concurrency boundary. It can prevent one client from silently replacing resource state after another client has changed the selected representation. It does not turn HTTP into a transaction protocol, lock the resource between requests, or guarantee that an entity tag represents every piece of application state involved in a mutation.

Software Engineering HTTP

Software Engineering / 16 Sep 2026 / 8 min read

HTTP 425 Keeps Replay-Sensitive Requests Out of TLS Early Data

TLS 1.3 can carry application data before a resumed handshake completes, which means an HTTP request can reach server processing earlier than the connection has its final handshake state. That latency optimization changes a security property: early data can be replayed, so a request that is safe to execute once can become unsafe when the same bytes are accepted more than once. HTTP status 425 Too Early marks the boundary between transport acceptance and application acceptance. A server can accept TLS early data at the connection layer yet decline to process a particular HTTP request from that data. The client can then retry after the handshake completes, where the early-data replay condition no longer applies.

Software Engineering HTTP

Software Engineering / 16 Sep 2026 / 7 min read

HTTP 421 Misdirected Request Marks a Connection Authority Boundary

An HTTP/2 client can reuse one secured connection for requests to more than one origin when the server is authoritative for those origins. A request can still reach a server instance whose connection context does not fit the target URI. 421 Misdirected Request exists for that boundary: the server rejects the routing context rather than treating the target resource itself as missing. This distinction separates resource semantics from connection authority. A 421 response says that this server, on this path or connection context, is unable or unwilling to produce an authoritative response for the target URI. It does not say that the resource has been deleted, that its method is forbidden, or that the request representation is invalid.

Software Engineering HTTP

Software Engineering / 16 Sep 2026 / 6 min read

HTTP 103 Early Hints Separate Speculation From Final Response Semantics

An HTTP server can emit a 103 Early Hints informational response before it has produced the final response. A client may act on suitable fields in that interim message, such as starting a preload named by Link, even though the eventual status code, header fields, and representation are still pending. This creates a deliberate split between speculative work and authoritative response semantics. The interim response can move selected preparation earlier in time, but it cannot stand in for the final response or determine its meaning.

Software Engineering HTTP

Cybersecurity / 16 Sep 2026 / 7 min read

HSTS Pins HTTP Navigation to an HTTPS-Only Origin Policy

HSTS Pins HTTP Navigation to an HTTPS-Only Origin Policy A browser receives a link beginning with http:// for a host it has contacted securely before. No HTTP request leaves the machine. Instead, the user agent rewrites the navigation to HTTPS from local policy and starts TLS directly. The server-side redirect that administrators often associate with HTTPS migration never participates in that request path. HTTP Strict Transport Security (HSTS), standardized in RFC 6797, creates this behavior by letting an HTTPS host declare a time-bounded transport policy. Once a conforming user agent records that policy, insecure HTTP is no longer a permissible transport choice for matching requests during the policy lifetime. This shifts an important boundary from server response handling to client-side connection selection.

Cybersecurity HTTP

Cybersecurity / 16 Sep 2026 / 7 min read

Fetch Metadata Lets Servers Reject Cross-Site Request Contexts

Fetch Metadata Lets Servers Reject Cross-Site Request Contexts An authenticated endpoint can receive a syntactically valid request carrying ambient credentials even when the navigation or resource load began on another site. Cookies alone do not tell the server what browser context produced the request. Fetch Metadata adds request headers that expose selected context already known to the user agent, giving the server another signal before it accepts a state-changing operation or serves a sensitive resource.

Cybersecurity Web Security

Software Engineering / 16 Sep 2026 / 6 min read

ETag Revalidation Separates Cache Freshness From Representation Transfer

An HTTP cache can hold a response that is no longer fresh yet still avoid downloading the representation again. When the stored response carries a usable validator, the cache can send a conditional request and let the origin confirm whether the selected representation has changed. This separates two operations that are often treated as one: checking whether cached state remains valid and transferring a new representation. A successful revalidation can perform the first without performing the second.

Software Engineering HTTP

Cybersecurity / 16 Sep 2026 / 8 min read

CORS Preflight Caching Extends Cross-Origin Policy Decisions

CORS Preflight Caching Extends Cross-Origin Policy Decisions An API operator can remove a cross-origin method from its CORS configuration and still see browsers issue that method without a fresh OPTIONS exchange. The browser may already hold a valid preflight cache entry authorizing the request shape. Until that entry expires or is discarded, the earlier policy decision can continue to suppress a new preflight. This behavior does not make CORS authorization permanent, and it does not bypass the CORS check on the actual response. It does create an operational interval in which a server-side policy change and browser preflight behavior are not synchronized. Access-Control-Max-Age therefore affects more than request volume: it influences the lifetime of a cached permission decision inside the user agent.

Cybersecurity CORS

Cybersecurity / 16 Sep 2026 / 8 min read

Cache Keys Define the Security Boundary of Shared HTTP Responses

Cache Keys Define the Security Boundary of Shared HTTP Responses A reverse proxy receives two requests for the same URL. One carries a header that changes the origin response; the other does not. If the proxy stores the first response under a key that ignores that header, the second request can receive content generated from state it never supplied. The cache is operating correctly according to its key, yet the key has merged two requests that the application treats as distinct.

Cybersecurity HTTP

Cybersecurity / 15 Sep 2026 / 8 min read

TLS 1.3 Early Data Trades a Round Trip for Replay Exposure

TLS 1.3 Early Data Trades a Round Trip for Replay Exposure A resumed TLS 1.3 connection can carry application bytes before the server has completed the new handshake. That latency reduction is attractive on paths where a round trip is expensive, but it changes a security property that applications often assume without naming it: a protected request is not necessarily fresh merely because the server decrypted it successfully. TLS 1.3 calls this facility early data, commonly described as 0-RTT. It is available when the client and server share a pre-shared key, including one established through a prior connection. The client can derive keys and send application data in its first flight rather than waiting for the server’s handshake messages.

Cybersecurity TLS 1.3

Cybersecurity / 15 Sep 2026 / 7 min read

HTTP Request Smuggling Starts at Message-Boundary Disagreement

HTTP Request Smuggling Starts at Message-Boundary Disagreement A reverse proxy can validate an HTTP request, forward it to an application server, and still leave both systems with different views of where that request ends. The bytes do not need to change in transit. The security failure appears when two parsers assign different boundaries to the same stream. That disagreement is the core of HTTP request smuggling. One component consumes a prefix as a complete request while another treats additional bytes as part of that request, or as the beginning of a following one. On a reused backend connection, the leftover bytes can alter the interpretation of traffic that arrives later.

Cybersecurity HTTP

Software Engineering / 15 Sep 2026 / 8 min read

HTTP Preconditions Turn Resource Versions Into Write Guards

A client reads a resource at revision 41, edits one field, and sends the whole representation back. During that interval, another client commits revision 42. If the server accepts the first client’s replacement without testing its source revision, revision 42 can disappear from the visible state even though both requests completed normally. This is the lost-update shape at an HTTP boundary. The notable detail is not simultaneous execution. The requests can arrive seconds apart. The conflict exists because a later mutation was derived from an earlier representation and the server has no condition connecting those two facts.

Software Engineering HTTP

Software Engineering / 15 Sep 2026 / 8 min read

Expect 100-Continue Defers Request Body Transfer

An HTTP/1.1 client can send request headers containing Expect: 100-continue and hold back the request body while the server evaluates those headers. The server can answer with 100 Continue, allowing body transfer to proceed, or send a final response when it can reject the request without receiving the payload. This splits one request into a metadata decision boundary followed, conditionally, by body transmission. The mechanism matters most when a request body is costly to transmit and the server can make a useful decision from request metadata alone. Authentication failure, an unsupported method, or another header-visible rejection can terminate the exchange before those bytes cross the connection. The same split also creates a timing dependency: a client cannot wait forever for an interim response, and servers and intermediaries must preserve the protocol semantics closely enough for progress.

Software Engineering HTTP

Cybersecurity / 14 Sep 2026 / 6 min read

HTTP Request Smuggling Exploits Parser Disagreement

HTTP Request Smuggling Exploits Parser Disagreement A reverse proxy and an application server can each parse the same byte stream according to rules that appear reasonable in isolation. Trouble starts when they reach different answers about where one request ends. Bytes treated as the tail of a request by the front end can become the start of another request at the back end, shifting the interpretation of traffic that follows on a reused connection.

Cybersecurity HTTP

Cybersecurity / 14 Sep 2026 / 7 min read

HTTP Request Framing Must Agree Across Every Hop

A reverse proxy can accept a byte sequence as one HTTP request while the application server behind it interprets part of the same sequence as the start of another. Neither component needs to contain a memory-safety defect. The security failure sits in the disagreement between their parsers. This is the central condition behind HTTP request smuggling. Modern web traffic commonly crosses several HTTP-speaking components before reaching application code: CDNs, load balancers, API gateways, service meshes, reverse proxies, and origin servers. Each hop has to determine where one request ends and the next begins. If two adjacent components derive different boundaries from the same traffic, bytes assigned to one request at the front end can acquire a different meaning downstream.

Cybersecurity Web Security

Cybersecurity / 14 Sep 2026 / 7 min read

Cache Keys Define the Security Boundary of Shared Responses

A reverse proxy can receive two requests that look different to an application and identical to its cache. That disagreement is enough to turn an ordinary performance feature into a cross-user security boundary. Shared HTTP caches are built around equivalence. A cache key decides which requests may reuse the same stored response. The origin application makes a separate decision about which request properties influence its output. Security problems appear when those two models diverge: the origin varies a response on data that the cache does not include in its identity for that response.

Cybersecurity Web Security

Go / 13 Sep 2026 / 5 min read

Set Per-Request Read Deadlines with http.ResponseController in Go

A server-level read timeout applies one policy across connections, but a particular handler can have a narrower request-body budget. Go’s http.ResponseController exposes SetReadDeadline for that case. The deadline covers reading the request, including its body, and gives handler code a direct boundary for input that arrives too slowly. This control is different from limiting body size. A byte limit constrains how much data a handler accepts; a read deadline constrains how long reads may continue. Endpoints that accept streamed or uploaded data often need both dimensions considered separately.

Golang HTTP

Cybersecurity / 13 Sep 2026 / 8 min read

HTTP Request Smuggling Begins With Parser Disagreement

HTTP Request Smuggling Begins With Parser Disagreement A reverse proxy can reject malicious paths, normalize headers, enforce authentication, and still pass an ambiguous HTTP message to a backend that interprets the same bytes differently. At that point, the security boundary is no longer defined by either component in isolation. It is defined by the gap between their parsers. HTTP request smuggling exploits that gap. The attacker is not primarily defeating TLS or guessing a credential. The useful primitive is message-boundary disagreement: one system decides that a request ends at one byte, while the next system decides that it ends somewhere else. Bytes treated as a body by the front end can become the start of another request at the origin, or the reverse can occur.

Cybersecurity Web Security

Cybersecurity / 13 Sep 2026 / 7 min read

HTTP Request Boundaries Fail When Intermediaries Disagree

A front-end proxy can accept a byte stream as one HTTP request while the server behind it interprets part of the same stream as the beginning of another. At that point, the disagreement is no longer a parsing curiosity. Bytes supplied by one connection can change how a later request is framed, creating a route around controls that assumed every component agreed on request boundaries. HTTP request smuggling sits in this gap between parsers. The vulnerable condition is not simply the presence of a Content-Length or Transfer-Encoding header. It is a chain in which two adjacent HTTP implementations assign different structure to the same traffic, then reuse a connection or otherwise preserve enough state for the disagreement to affect subsequent processing.

Cybersecurity HTTP

Cybersecurity / 13 Sep 2026 / 7 min read

Host Header Trust Can Turn Application URLs Into Attacker Input

A web application can serve the correct page, validate the correct account, and still emit a security-sensitive link pointing at a domain controlled by somebody else. The failure often begins with a value that looks operational rather than privileged: the HTTP host presented with the request. Modern deployments make host handling deceptively complex. A browser sends authority information, an edge proxy may rewrite it, another proxy may add a forwarding header, and the application framework eventually exposes a convenient property representing the apparent host. That property is useful for routing and URL generation. It is dangerous when the application treats it as an authenticated statement about its own public identity.

Cybersecurity Web Security