Keep HTTP request boundaries consistent across intermediaries

A reverse proxy and an application server can each parse the same connection successfully while disagreeing about where one request ends. The downstream component may then interpret leftover bytes as part of another request. This can undermine an edge authorization decision or associate responses with the wrong request. The defect is a disagreement across a chain, not simply the presence of an unusual header.

Draw the actual chain: browser or API client, CDN, load balancer, service proxy and origin. Record the protocol on each link and whether upstream connections are reused. A front end accepting HTTP/2 does not prove its HTTP/1.1 origin hop is safe. Upgrade tunnels, protocol translation and runtime versions belong in that inventory. A check against one process cannot certify an untested intermediary.

The fixture uses PING as four harmless ASCII bytes. In B, the visible sequence 0\r\n\r\nPING contains nine bytes. A defective parser that chooses Content-Length: 9 consumes all nine as the body. A chunked parser reads the zero-sized terminating chunk and the final empty line after five bytes, leaving four bytes. PING is not a complete HTTP request; this exercise demonstrates disagreement without constructing a second request.

RFC 9112 §6.3 defines the framing precedence: Transfer-Encoding overrides Content-Length, a message with both "ought to be handled as an error", and an intermediary that forwards one must first remove the Content-Length. An invalid Content-Length is an unrecoverable error that a server answers with 400 before closing the connection. RFC 9110 §8.6 adds one exception: a recipient of the same value repeated, such as Content-Length: 42, 42, may either reject the message or replace the field with the single value, which RFC 9112 then uses. This site's local project deliberately adopts a narrower acceptance policy: reject requests containing both Transfer-Encoding and Content-Length, reject duplicate length fields, and close on a parser error. That stricter rule is permitted, but it is not the only standards-conforming behavior.

A: Content-Length: 4; body bytes = PING
B: Content-Length: 9 AND Transfer-Encoding: chunked; body = 0\r\n\r\nPING
C: Content-Length: 4 AND Content-Length: 5; body = PING
D: Content-Length: 6; only PING arrives, then EOF
E: Authorization: Bearer alice AND Authorization: Bearer bob
Lab policy: one unambiguous framing interpretation; no duplicate identity fields.

The classic cases disagree about which length header wins; later research found disagreements in protocol translation, in servers that ignore a body, and in Expect handling. In 2025 PortSwigger reported 0.CL and Expect-based desyncs affecting major CDNs, including CVE-2025-32094 in Akamai, and concluded that HTTP/1.1 between proxy and origin is the root problem.

Application code normally receives an already parsed request. If the HTTP parser accepts contradictory framing, a handler cannot reliably repair the original wire interpretation after the fact. Keep maintained parsers in their strict mode, reject rather than guessing at malformed traffic, and ensure an error does not leave the connection reusable with unread bytes.

A separate problem appears when normalized header objects discard duplicate values. For E, the parsed headers object may expose only Alice even though two authorization fields arrived. Counting raw header names before deriving identity allows the application boundary to reject this ambiguity. This is not a substitute for framing enforcement; identity fields and message-length fields fail at different layers.

In the Node project, both origin and proxy use the default strict HTTP parser. A clientError handler sends 400 and closes the socket. The proxy also rebuilds the forwarded header set from an allowlist, so caller-supplied verified-identity headers never become trusted origin metadata. Response hop-by-hop framing is removed before Node generates the outgoing response framing.

HTTP/2 carries each request in its own frames with an explicit end, so a proxy and an origin cannot disagree about length the way two HTTP/1.1 parsers can; RFC 9113 also makes Transfer-Encoding illegal in HTTP/2. nginx added HTTP/2 to upstreams in 1.29.4 and ships it in the 1.30 stable branch; HAProxy, Envoy and several CDNs can also speak HTTP/2 to the origin. Clients can keep using HTTP/1.1 to reach the edge. Keep every HTTP/2 hop patched against the stream attacks in the layer 7 DDoS guide at /domains/runtime/availability/l7-ddos-resilience/.

Check the defaults of the version you run. nginx 1.29.7 changed proxy_http_version to 1.1 and enabled upstream keepalive (keepalive 32 local), so a default nginx 1.30 now reuses HTTP/1.1 connections to the origin; in a test, three requests to a Node.js origin shared one connection, while keepalive 0 opened one connection per request. Disabling reuse costs latency and origin capacity, so treat it as a stopgap for an origin that cannot speak HTTP/2. The configuration below was tested with nginx 1.30.5: requests reached the origin as HTTP/2 over verified TLS, and the edge answered 400 or 501 to every ambiguous probe.

# nginx 1.30: speak HTTP/2 to the origin, so no HTTP/1.1 framing crosses that hop
upstream origin {
    server origin.internal:8443;
}

# Stopgap for an origin that only speaks HTTP/1.1: since 1.29.7 nginx reuses
# upstream connections by default (keepalive 32), so turn reuse off
upstream legacy_origin {
    server legacy.internal:8081;
    keepalive 0;
}

server {
    listen 443 ssl;
    server_name api.example.test;
    ssl_certificate     /etc/nginx/certs/edge.crt;
    ssl_certificate_key /etc/nginx/certs/edge.key;

    location / {
        proxy_pass https://origin;
        proxy_http_version 2;                 # 1.29.4+; run 1.30.1+ for CVE-2026-42926
        proxy_ssl_server_name on;
        proxy_ssl_name origin.internal;
        proxy_ssl_verify on;
        proxy_ssl_trusted_certificate /etc/nginx/certs/origin-ca.crt;
    }

    location /legacy/ {
        proxy_pass http://legacy_origin;
    }
}

Download the proxy/cache project from the local projects section linked with this guide. It starts two real servers on 127.0.0.1 with automatically assigned ports. No production domain, account or external target is involved. Raw socket tests deliver the conflicting framing to the proxy; an origin-hit counter establishes whether any application work occurred.

Run node --test exercise.test.mjs. The deliberately incomplete starter has four passing and eight failing cases across cache and header policy. Conflicting transfer/length and duplicate length tests already pass because the strict parser is supplied. Repair validHeaders in exercise.mjs to reject duplicate singleton identity headers, then complete the cache contract covered by the companion caching guide at /domains/runtime/edge-defense/cache-poisoning-deception/. EXERCISE_MODULE=reference node --test exercise.test.mjs should pass all twelve tests.

Inspect both the wire response and the origin counter. A 400 status without an origin observation is weaker evidence than 400 plus zero origin hits. Conversely, a successful ordinary POST with the correct body demonstrates that the repair has not simply disabled requests. The test’s one-request connections are sufficient for these rejection checks but do not reproduce a production persistent connection pool.

For each hop, retain exact product and runtime versions, strictness settings, accepted protocols and a diagram of translation boundaries. Test malformed cases in an isolated instance of that chain, with synthetic identities and observable origin counters. Do not treat the Node fixture as evidence for a different CDN or vendor proxy.

When translating protocols, test what the next hop receives after the translation. An HTTP/2 message with a Transfer-Encoding field or a content-length that does not match its DATA frames is malformed under RFC 9113 and must not be forwarded as HTTP/1.1. Examine duplicate pseudo-header and header treatment, prohibited hop-specific fields, length consistency and connection or stream error behavior using the relevant product's supported options. Configuration names and defaults vary; copy neither an obsolete hardening list nor another product's setting without verifying the installed version.

The probe below sends six raw requests and prints each status line. Against nginx 1.30.5 and against a default Node.js 26.3.0 server, the valid chunked control returned 200 and every ambiguous case was rejected: 400 for both length fields, conflicting lengths, whitespace before the colon and a bare line feed in a chunked body, and 501 from nginx (400 from Node.js) for Transfer-Encoding: xchunked. Run it only against a disposable copy of your own chain.

Contain a suspected disagreement by taking the affected path or version out of service under the incident process and invalidating any affected cache entries. Redacted request identifiers, routing decisions, parser errors and origin request counts help determine scope. Avoid retaining raw credentials or sensitive request bodies merely to make logs more detailed.

// Send raw HTTP/1.1 requests with ambiguous framing to a disposable test chain and print each
// response's status line. Then check the origin's access log: no rejected probe may appear there.
// Usage: node probe-framing.mjs <host> <port>
import net from 'node:net';

const [host, port] = [process.argv[2], Number(process.argv[3])];
const head = 'POST /probe HTTP/1.1\r\nHost: example.test\r\nConnection: close\r\n';
const cases = {
  'valid chunked (control)': head + 'Transfer-Encoding: chunked\r\n\r\n4\r\nPING\r\n0\r\n\r\n',
  'CL.TE: both length fields': head + 'Content-Length: 9\r\nTransfer-Encoding: chunked\r\n\r\n0\r\n\r\nPING',
  'conflicting Content-Length': head + 'Content-Length: 4\r\nContent-Length: 5\r\n\r\nPING',
  'TE obfuscation: xchunked': head + 'Transfer-Encoding: xchunked\r\nContent-Length: 4\r\n\r\nPING',
  'whitespace before colon': head + 'Transfer-Encoding : chunked\r\nContent-Length: 4\r\n\r\nPING',
  'bare LF in chunked body': head + 'Transfer-Encoding: chunked\r\n\r\n4\nPING\n0\n\n',
};
for (const [name, raw] of Object.entries(cases)) {
  const reply = await new Promise(resolve => {
    let data = '';
    const socket = net.connect(port, host, () => socket.write(raw));
    socket.setTimeout(3000, () => socket.destroy());
    socket.on('data', chunk => (data += chunk));
    socket.on('close', () => resolve(data));
    socket.on('error', () => resolve(data));
  });
  console.log(`${name.padEnd(28)} ${reply.split('\r\n')[0] || '(closed without a response)'}`);
}

These results apply to the supplied strict lab contract. Capture a permitted case beside each denial and record which component rejected the invalid input.

The local project exercises HTTP/1.1 parsing and a single Node implementation on both sides. It does not model HTTP/2 multiplexing, a browser, TLS termination, multiple proxy vendors, request trailers or a production cache. The capstone is to replace one hop with your maintained deployment stack in a disposable environment and preserve the same observations. A scanner label alone is not the evidence; the boundary disagreement and its business effect are what the review must explain.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. RFC 9112: HTTP/1.1 framing and request smuggling. June 2022.
2. Node.js HTTP parser and raw headers. Node.js v26.11.1.
3. Envoy HTTP protocol options
4. RFC 9110 §8.6: Content-Length. RFC 9110 (June 2022).
5. RFC 9113: HTTP/2. June 2022.
6. PortSwigger Research: HTTP/1.1 must die (2025)
7. PortSwigger Web Security Academy: HTTP/2 downgrading
8. nginx: ngx_http_proxy_module
9. nginx: changes in the 1.30 stable branch
10. PortSwigger: HTTP Request Smuggler

Reference information

RFC 9110, 9112 and 9113; nginx 1.30.5 and Node.js 26.3.0 tested on 2026-10-10; Node.js 22+ loopback project.

Tags

Proxies, caches and request smuggling

SDLC phase

Maintenance

Role

DevelopersPlatform engineers and SREs

ASVS 5.0.0 requirements

v5.0.0-4.2.1 · v5.0.0-4.2.2 · v5.0.0-4.2.3

CAPEC attack patterns

• CAPEC-33 at MITRE

Download this guide as Markdown

Continue exploring