UA emulation causes connection error (possibly HTTP/2–related)

[ntrippar]

I’ve found an issue when UA emulation is used it causes connection error

Working command

cargo run -p rama-cli -- -v --show-headers --insecure \
  'https://dsp-cookie.adfarm1.adition.com/?ssp=5&gdpr=0&gdpr_consent='

Output

* Connection established to peer with IPv4: 80.82.210.217
* ALPN: rama offers h2,http/1.1
* TLS Connection using version TLSv1_3
* ALPN: server selected h2
* Server Certificate:
*  subject: CN=dsp-cookie.adfarm1.adition.com
*  start date: Dec  8 03:00:24 2025 GMT
*  expire date: Mar  8 03:00:23 2026 GMT
*  subjectAltNames: DNS=dsp-cookie.adfarm1.adition.com
*  issuer: C=US, O=Let's Encrypt, CN=R12
* using HTTP/2.0
* [HTTP/2] [:method: GET]
* [HTTP/2] [:scheme: https]
* [HTTP/2] [:authority: dsp-cookie.adfarm1.adition.com]
* [HTTP/2] [:path: /]
> GET /?ssp=5&gdpr=0&gdpr_consent= HTTP/2.0
> host: dsp-cookie.adfarm1.adition.com
> user-agent: rama/0.3.0-alpha.4
>
* HTTP/2.0 302 Found
* [HTTP/2] [:status: 302 Found]
< date: Sun, 21 Dec 2025 22:12:51 GMT
< p3p: policyref="http://imagesrv.adition.com/w3c/p3p.xml",CP="NON DSP ADM DEV PSD IVDo OTPi OUR IND STP PHY PRE NAV UNI"
< set-cookie: UserID1=7586437692600613227; Max-Age=7776000; domain=.adfarm1.adition.com; Path=/; SameSite=None; Secure
< location: https://rtb-csync.smartadserver.com/redir/?issi=1&partnerid=49&partneruserid=7586437692600613227&gdpr=0&gdpr_consent=
< content-length: 0
< x-envoy-upstream-service-time: 0
< server: envoy

Failing command (with UA emulation)

cargo run -p rama-cli -- -v --show-headers --insecure --emulate \
  'https://dsp-cookie.adfarm1.adition.com/?ssp=5&gdpr=0&gdpr_consent='

Error output

* Connection established to peer with IPv4: 80.82.210.217
* ALPN: rama offers h2,http/1.1
* TLS Connection using version TLSv1_3
* ALPN: server selected h2
* using HTTP/2.0
* [HTTP/2] [:method: GET]
* [HTTP/2] [:authority: dsp-cookie.adfarm1.adition.com]
* [HTTP/2] [:scheme: https]
* [HTTP/2] [:path: /]
> GET /?ssp=5&gdpr=0&gdpr_consent= HTTP/2.0
> sec-ch-ua: "Microsoft Edge";v="143", "Chromium";v="143", "Not A(Brand";v="24"
> sec-ch-ua-mobile: ?0
> sec-ch-ua-platform: "Windows"
> upgrade-insecure-requests: 1
> user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36 Edg/143.0.0.0
> accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
> sec-fetch-site: none
> sec-fetch-mode: navigate
> sec-fetch-user: ?1
> sec-fetch-dest: document
> accept-encoding: gzip, deflate, br, zstd
> accept-language: en-US,en;q=0.9
> priority: u=0, i
> host: dsp-cookie.adfarm1.adition.com
>
🚩 exit with error: send command
 ↪ http request failure for uri: https://dsp-cookie.adfarm1.adition.com/?ssp=5&gdpr=0&gdpr_consent=
 ↪ connection error

Expected behavior

Both commands should succeed and return a response, regardless of whether UA emulation is enabled.

Actual behavior

The request fails with a connection error when --emulate is used.

Notes / hypotheses

• I plan to sniff both requests to compare them and after I verify this with wireshark will report back with packet-level details.

• My suspicion is that when UA emulation is enabled and HTTP/2 is used, an invalid or non-compliant header (or frame) is being added.

• One possible issue could be related to :authority vs Host handling in HTTP/2, per RFC 9113:

  The recipient of an HTTP/2 request MUST NOT use the Host header field to determine the target URI if “:authority” is present.
  https://www.rfc-editor.org/rfc/rfc9113.html#section-8.3.1-2.3.1

• Another possibility is something related to the PRIORITY frame or other HTTP/2–specific behavior.

  https://www.rfc-editor.org/rfc/rfc9113.html#section-6.3

[seuros]

Investigation Results

Root cause identified: The Chrome H2 early frames are causing the connection to be rejected by this specific server.

Analysis

The Chrome profile includes these H2 early frames:

1. SETTINGS with initial_window_size: 6291456 (6MB - much larger than the default 65535)
2. WINDOW_UPDATE on stream 0 with size_increment: 15663105 (~15MB)

These frames are sent immediately after the TLS handshake, before any HEADERS frame.

Test Results

Test	Result
Without --emulate	✅ Works
With --emulate	❌ "connection error"
With --emulate + skip early frames	✅ Works
curl against same server	✅ Works
nghttp against same server	✅ Works
rama with --emulate against httpbin.org	✅ Works

Comparison

Working clients (curl, nghttp, rama without emulation):

• Use standard H2 SETTINGS (default initial_window_size = 65535)
• No early WINDOW_UPDATE on stream 0

Failing (rama with emulation):

• Chrome-like SETTINGS with large initial_window_size (6MB)
• Early WINDOW_UPDATE adding 15MB to connection-level flow control

Hypothesis

The server (Envoy-based) likely has one of:

1. Strict flow control validation rejecting very large window sizes
2. Issue handling WINDOW_UPDATE on stream 0 before any data streams exist
3. A max window size limit that's exceeded

Verification

Added temporary debug code to skip early frames:

let early_frames = if std::env::var("RAMA_DEBUG_SKIP_EARLY_FRAMES").is_ok() {
    None
} else {
    profile.h2.settings.early_frames.clone()
};

With RAMA_DEBUG_SKIP_EARLY_FRAMES=1, the emulated request works:

RAMA_DEBUG_SKIP_EARLY_FRAMES=1 target/debug/rama -v --show-headers --emulate --insecure \
  'https://dsp-cookie.adfarm1.adition.com/?ssp=5&gdpr=0&gdpr_consent='
# Returns HTTP/2.0 302 Found ✅

Potential Fixes

1. Make early frames optional - Add a flag to skip early frames for compatibility
2. Reduce window sizes - Use more conservative values that work with strict servers
3. Server-specific detection - Detect servers that reject large windows and fallback

The early frames are accurate to what Chrome sends, so this is technically a server compatibility issue, but having a workaround would be helpful.

[GlenDC]

The recipient of an HTTP/2 request MUST NOT use the Host header field to determine the target URI if “:authority” is present.

Such headers are removed before:

rama/rama-http-backend/src/client/svc.rs

Lines 245 to 260 in 80f6ed5

	// remove illegal headers
	for illegal_h2_header in [
	&CONNECTION,
	&TRANSFER_ENCODING,
	&PROXY_CONNECTION,
	&UPGRADE,
	&SEC_WEBSOCKET_KEY,
	&KEEP_ALIVE,
	&HOST,
	] {
	if let Some(header) = req.headers_mut().remove(illegal_h2_header) {
	tracing::trace!(
	http.header.name = ?header,
	"removed illegal (~http1) header from h2 request",
	);
	}

---

Anyway seems you both already figured out it's to do with the h2 meta frames. Going to look into it now.