Alt-Svc: advertised HTTP/3 port is parsed and stored but never used

[passcod]

🤖 AltSvcCache::should_use_h3 returns the advertised HTTP/3 port, but AltSvcMiddleware::handle only uses it as a boolean:

let trying_h3 = self.cache.should_use_h3(&url).is_some();

The port is parsed from the Alt-Svc header, stored in AltSvcEntry, threaded through record_alt_svc / add_hint / confirm_h3 — and then never used to route anything. The request URL is not rewritten, so faith only ever attempts HTTP/3 on the origin's own port.

Consequences:

• A server advertising alt-svc: h3=":8443" on an origin served at :443 gets an h3 attempt on :443. If nothing listens on UDP :443, every attempt is futile — best case it fails fast and falls back, but it's wasted work on every request until the failure is cached.
• Conversely, an origin at :8443 advertising h3=":443" gets h3 attempted on :8443, silently ignoring the advertisement.
• This matters for split TCP/UDP frontends. The consumer who reported test: cover the HTTP/3 fallback that cancellation skips #23 also runs Envoy Gateway in Kubernetes, where the advertised h3 port need not match the origin port.

Note this is load-bearing by accident in some setups today: because the port is ignored, a server whose advertised port is unreachable from the client still gets h3 attempted on the working origin port.

Upstream constraint: reqwest keys its HTTP/3 pool on (scheme, authority) derived from the request URI (h3_client/pool.rs), and H3Connector::connect takes the port from that URI. Honouring a different advertised port means connecting to one endpoint while keeping the original origin's Host and TLS SNI — which is exactly what Alt-Svc means, but reqwest has no API for it. So this likely needs upstream work rather than a fix confined to alt_svc.rs.

Minimum viable improvement without upstream changes: only attempt h3 when the advertised port equals the origin port, and otherwise don't upgrade (rather than upgrading against the wrong port). That trades a silently-wrong attempt for a correctly-skipped one.

Found while investigating #23; not the cause of that bug.

[passcod]

🤖 Traced where this limitation actually lives, since it determines whether it's fixable here at all.

It's reqwest's, in src/async_impl/h3_client/. Everything below already supports what Alt-Svc needs; everything above has no hook.

• quinn — Endpoint::connect(addr: SocketAddr, server_name: &str). Dial address and TLS name are independent arguments. No constraint.
• h3 — client::new(conn) takes an already-established connection and returns a SendRequest; you then send an http::Request whose :authority comes from its own URI. Connection and claimed authority are decoupled by construction — exactly the Alt-Svc shape.
• reqwest — conflates them. H3Client::request calls extract_domain(req.uri_mut()) for the pool key, then domain_as_uri(key) to produce the dial target. The connect target is the request authority, with no override. reqwest has no Alt-Svc support at all, which is why faith carries its own middleware.

The one workaround you'd reach for is explicitly closed. resolve_to_addrs (faith's dns.overrides) accepts a port, but the h3 connector discards it:

let port = dest.port_u16().unwrap_or(443);
let addrs = resolve(&mut self.resolver, Name::from_str(host)?).await?;
let addrs = addrs.map(|mut addr| { addr.set_port(port); addr });  // resolver's port dropped

So DNS overrides can redirect the TCP target but not the HTTP/3 one.

Upstream tracking: seanmonstar/reqwest#1138 — "Alternative HTTP services", open since January 2021, labelled B-rfc. It names this precisely: "reqwest does not allow for prior-knowledge alternative services: the API takes the request's URL and then looks up the hostname from there."

What the upstream change would be, if anyone picks it up. The call chain is three functions deep:

request(&self, mut req)                    // extract_domain(req.uri_mut()) -> pool_key
  └─ send_request(self, key: Key, req)     // passes key straight through
       └─ get_pooled_client(&mut self, key: Key)
            let dest = pool::domain_as_uri(key.clone());   // dial target derived FROM the key
            let (driver, tx) = self.connector.connect(dest).await?;

Thread a dial target alongside the key instead of deriving it from the key, plus a public request-extension type for callers to set it. Roughly 30-50 lines. Two things then fall out correctly with no extra work: SNI stays right (the connector passes host, unchanged by a port override), and :authority stays right (PoolClient::send_request sends the original http::Request). The only real design question is whether the pool key stays the origin authority or becomes (origin, dial_target) — the latter is safer, so a changed advertisement forces a re-dial rather than reusing a connection to the old endpoint.

Resolved in #29 as far as it can be here: by default faith no longer upgrades when the advertised port differs from the origin's, since the advertisement isn't evidence about the origin's own port. http3.upgradeFollowAdvertisedPort opts into rewriting the request's port anyway — not standards-compliant, and documented as such — for people who control their servers and would rather not wait on upstream.