Browser connection pools as a desync boundary

Persistent HTTP/1 connections depend on both peers consuming exactly the same message. A server that responds to a POST while leaving its body in the input stream may let that body become the beginning of a later request sent by the browser.

Research anchor and scope

James Kettle’s browser desync paper describes a client-side boundary between browser and server, requiring browser-sendable requests and vulnerable connection reuse. It distinguishes early responses that safely consume or discard bodies from true desynchronization. Its browser experiments also track credential-related connection pools. HTTP/2 preference, browser policy, and proxy behavior materially affect whether a historical HTTP/1 scenario can be reproduced today.

Establish the protocol state

Record the negotiated protocol, whether the server closes after its early response, and whether a follow-up reuses the same connection. An endpoint returning an error before its complete body arrives is only a candidate. Secure implementations can respond early while still draining the declared body before parsing the next request.

Use a local toy endpoint that ignores a supplied POST body and retains its connection. Put a distinctive harmless path in the body, then request a different path on that same connection. If the second response corresponds to the body path, inspect the parser state and repeat with a different marker. This is stronger evidence than a generic unexpected status code.

Move from tools to the browser

A handcrafted client can set headers that browser JavaScript cannot. Reduce the candidate to browser-controlled method, URL, body, and permitted content type. Confirm the browser actually sends the intended bytes. Cross-origin restrictions govern response access, but a response that cannot be read can still leave a connection in a dangerous state.

Inspect connection identifiers and navigation timing in developer tools. Account for separate pools, preconnects, redirects, service workers, and connection partitioning. A successful proxy-assisted experiment may be using HTTP/1 only because the proxy changes protocol negotiation. Repeat the essential test without that proxy before attributing it to normal browser behavior.

State the primitive and its limits

An arbitrary request prefix on one browser connection is not yet credential theft or JavaScript execution. Find a separate response or storage behavior that consumes that prefix in a useful way, then demonstrate it with controlled data. The timing and browser reuse conditions must survive that additional step.

Reject false positives caused by normal HTTP pipelining, endpoints that emit duplicate responses, or a tool displaying unread bytes from an earlier run. Repeat with a fresh connection and an unambiguous baseline. This technique concerns stream synchronization and ambient browser authority; it does not require the same shared-backend connection model as a server-side cross-user desync.