How Middleboxes Rewrite Requests in Transit

Detection often assumes a request arrives as the browser constructed it. Between the browser and the server sits a variable amount of equipment, and much of it modifies what passes through.

Header ordering does not survive normalisation

Browsers emit headers in a consistent order that reflects how their networking code is written, which makes ordering a usable signal when it arrives intact.

Many proxies rebuild requests from a parsed representation, which means headers are re-emitted in whatever order that implementation uses rather than the order they arrived in.

Protocol translation destroys ordering more thoroughly, since a request received over one protocol version and forwarded over another is reconstructed rather than relayed.

Fields are added, removed and rewritten

Forwarding equipment routinely appends headers describing the original client and the path taken, and these are self-reported data added by an intermediary rather than anything the client said.

Compression preferences are commonly rewritten so the intermediary can inspect or cache content, which means the preference the server sees is the appliance's rather than the browser's.

Some appliances strip headers they do not recognise, so newer browser features can vanish in transit and make a current browser look like an older one.

Connection reuse decouples requests from clients

Intermediaries pool connections to the origin and multiplex many users' requests over them, so connection-level properties describe the pool rather than any visitor.

Requests from different people arrive on the same connection, which breaks any logic that treats a connection as belonging to a session.

This is why connection-level and request-level evidence must be joined explicitly rather than assumed to describe the same client.

Optimisation appliances change content and timing

Products that compress images, rewrite markup or prefetch resources generate requests the user never initiated and alter the timing relationships between the requests that remain.

Prefetching in particular produces fetches with no preceding interaction, followed by a page view that appears instantaneous because the content was already retrieved.

Both patterns resemble automation, and the appliance is invisible to both the browser and the server that are trying to reason about each other.

Signals must be evaluated where they are intact

The practical conclusion is that request-formatting signals are only meaningful at the first point of termination, which for most sites is the delivery network edge rather than the origin.

Logic that depends on ordering or exact header composition needs to run there and pass a conclusion downstream. Running it at the origin measures the intermediary, and treating the result as evidence about the visitor produces confident errors.