Upstream Sync Report 2026-08-27: net/http idle-pool race and HTTP/2 IDNA consistency

Upstream changes

• golang/go@88b2ccb — net/http: add multiplexed connections to the idle pool prior to delivery

  • Adds HTTP/2 and HTTP/3 connections to the idle pool before delivering them to the waiting request.
  • Fixes a race where CloseIdleConnections can run before a multiplexed connection is visible in the idle pool.

• golang/go@2117d7c — net/http: use consistent IDNA processing for h1 and h2

  • Aligns net/http and the bundled HTTP/2 implementation on idna.Lookup.ToASCII with an ASCII fast path.
  • Prevents HTTP/2 pool lookups from using a different host normalization than net/http.

Impact on req

• transport.go still follows the old ordering in dialConnFor: it delivers an alternate connection to the waiting request first and only puts it in the idle pool afterward. This leaves the same CloseIdleConnections race present for HTTP/2 and HTTP/3.
• http.go already uses the aligned idna.Lookup.ToASCII behavior with an ASCII fast path.
• internal/http2/transport.go still uses idna.ToASCII in authorityAddr without the ASCII fast path, so HTTP/2 connection-pool keys can diverge from the root transport's normalized address for IDN hosts.

Suggested action

• Port 88b2ccb into transport.go, preserving req's custom transport behavior.
• Align internal/http2/transport.go with the IDNA normalization used by http.go.
• Add regression coverage for closing idle connections while an alternate connection is being delivered, and for IDN-based HTTP/2 connection reuse.

Start in transport.go at dialConnFor and compare its ordering with upstream commit 88b2ccb. Then inspect internal/http2/transport.go authorityAddr alongside the IDNA behavior already present in http.go. Done means both upstream fixes are adapted to req's transport behavior and regression coverage exercises idle-connection closing during delivery and IDN-based HTTP/2 reuse.