Countering HTTP/1.1 smuggling by only sending canonical messages

On 10/22/25 10:54, Ben Schwartz wrote:
> I think this draft identifies a real problem, but I'm not convinced that this is the right solution.
> 
> As a defense against request smuggling, this header is only a partial defense:
> 1.Both parties must upgrade their software to benefit.  This is a particularly serious limitation because the relevant parties are specifically those with limited ability to upgrade their software (otherwise they would be using HTTP/2).
> 2. Not all known parser confusion attacks are prevented, as noted by others in this thread.
> 3. It's not clear how to use it without TLS.  TLS may not be in use when the intermediary and backend are inside a single deployment (or even a single host!).
> 
> There are many other strategies that we could explore that would be easier to deploy and/or more effective.
> 
> A. Declare a limitation on the reuse of HTTP/1.1 connections, similar to draft-ietf-httpbis-optimistic-upgrade.  For example, this might say "when speaking to a potentially vulnerable server, an intermediary MUST NOT reuse a single HTTP/1.1 connection for requests from multiple clients (unless they are mutually trusting)".  This reduces efficiency, but anyone who cares about efficiency shouldn't be using HTTP/1.1.
> B. Confirm the HTTP/1.1 parser state between requests.  For example, an intermediary could inject a request like "TRACE /.well-known/barrier/$random HTTP/1.1" after each forwarded request, and check that the TRACE response is received correctly before forwarding the next request.
> C. Document a simple profile of HTTP/2 (e.g. SETTINGS_HEADER_TABLE_SIZE=0, SETTINGS_MAX_CONCURRENT_STREAMS=1, etc.)
> D. Define new header fields to demarcate the header section (e.g. "Begin-Headers: (unpredictable value) ... End-Headers: (same value)").  This could be extended to cross-check the header in various ways (e.g. enumerating the payload length of each header field).

What about requiring requests sent upstream, and responses sent
downstream, to use a canonical serialization?  My understanding is that
most smuggling attacks rely on unusual HTTP requests and responses, so
a canonical serialization is much more likely to be parsed correctly.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)