Safari iOS Fails from SETTINGS_WT_MAX_SESSIONS

[jlukic]

Thanks for your library its made my life a lot easier and has worked brilliantly. Have a bug report for you from my testing that was preventing Safari from working in my testing on iOS. (Unsure of Mac/Safari as i don't have any to test from)

Quick Version

A server using empty Config advertises SETTINGS_WT_MAX_SESSIONS = 2^62-1 but none of the three WT_INITIAL_MAX_* settings.

• This causes Safari to refuse the session before sending the extended CONNECT request.
• In v0.11.0 it sent all four and is accepted.

Client-side the refusal is a WebTransportError with an empty message about 50 ms after construction, which is what makes this hard to diagnose.

Reproduction

I've set up two live endpoints for testing this you can use.

• https://echo.semantic-ui.com:4433/echo — v0.12.0, nil Config
• https://echo.semantic-ui.com:4436/echo — v0.11.0, defaults

You can also run this bug specifically from any iphone/ipad from Safari at:
https://echo.semantic-ui.com/exhibits/quic-go

More debug tools at https://echo.semantic-ui.com

Source Truth

Issue verified in master at 23b4cd1, and ConfigureHTTP3Server there still sets WT_MAX_SESSIONS alone

[Tuhis]

To my understanding, this seems to happen also with desktop Safari (26.5.2).

[gtinneyprophecy]

We hit this in production and can add two data points, one of which suggests the missing WT_INITIAL_MAX_* settings are not the whole story.

Setup: game servers built on webtransport-go, serving browser clients (Chrome, Firefox, Safari). Client is plain browser WebTransport — for Safari, dialed by DNS name with an ordinary CA-issued certificate (no serverCertificateHashes).

1. Reproduced the issue as filed. On v0.12.0 with a nil webtransport.Config, iOS Safari 26.x fails every session (WebTransportError shortly after construction; the CONNECT never arrives server-side). Chrome and Firefox are unaffected. Your echo.semantic-ui.com:4433 / :4436 endpoints reproduce exactly the same split on our devices.

2. Advertising the settings did not fix it. We deployed v0.12.0 with a non-nil Config (MaxIncomingStreams: 256, MaxIncomingUniStreams: 256, MaxIncomingData: 1 << 40), i.e. addSettings emitting all three WT_INITIAL_MAX_* alongside WT_MAX_SESSIONS — and iOS Safari still failed identically against that server (verified with the Chrome samples WebTransport client page pointed at our live endpoint, same device that passes against :4436). So on our evidence, v0.12.0 has an additional Safari incompatibility beyond the selective settings advertisement.

Workaround we shipped: downgraded to v0.11.0 (with quic-go v0.60.0, since v0.11.0 uses http3.ParseCapsule, removed in v0.61.0). Safari completes handshakes, sessions and bidirectional streams against v0.11.0 in production. One migration note for anyone following: v0.11.0 does not wire the http3.Server in Server.init the way v0.12.0 does — without an explicit ConfigureHTTP3Server call the server advertises no WT settings and every client fails with "server didn't enable WebTransport".

We have not captured a packet-level diff of v0.11-vs-v0.12 SETTINGS/CONNECT against Safari, so we can't say which remaining difference Safari objects to.