fix(relay): default interop image to WebTransport at root path#34
Merged
Conversation
The moq-interop-runner's docker harness dials the relay at a path-less https://relay:4443 (WebTransport, ALPN "h3") and provides no env knob to select the relay's transport. The interop relay image defaulted to raw QUIC (MOQT_TRANSPORT=quic), so it advertised only the moqt-* ALPNs and rejected every h3 ClientHello with "tls: no application protocol" — every client connecting to a moq-go relay in docker failed, including moq-go -> moq-go (0/6). Default the interop entrypoint/Dockerfile to MOQT_TRANSPORT=webtransport and MOQT_WEBTRANSPORT_PATH=/ to match the harness, and skip the relay's "/" catch-all 404 handler when the WebTransport path is "/" (registering two handlers for the same pattern panics the ServeMux; a root-mounted upgrade already covers every request). The -webtransport and -webtransport-path binary flag defaults are unchanged, so local `go run ./cmd/relay` is unaffected. Verified through the runner's compose: moq-go -> moq-go docker goes from 0/6 to 6/6. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Flipping the relay image default to WebTransport (so the external moq-interop-runner, which has no transport knob, can reach it) broke this repo's own "our client → our relay" CI job: `make interop-client` defaults to a raw-QUIC loopback (moqt://relay:4443), and its relay relied on the image's old quic default. With the relay now defaulting to WebTransport it advertised only h3, so the moqt:// client failed with "tls: no application protocol". docker-compose.client.yml now defaults the relay's MOQT_TRANSPORT to quic (matching the moqt:// loopback URL), and the Makefile derives it from CLIENT_RELAY_URL's scheme so an https:// override stays consistent. Third-party relay images ignore MOQT_TRANSPORT. interop/docker-compose.yml already forwarded MOQT_TRANSPORT, so interop-quic/interop-webtransport are unaffected. Verified: `make interop-client` loopback passes 6/6 with the relay in QUIC mode. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The
2026-06-29interop run had moq-go failing every docker pairing, includingmoq-go → moq-go(0/6) — a same-implementation pairing failing points at our own image, not a peer.The runner's docker harness (
docker-compose.test.yml+make test) is hardwired to one transport: the client'sRELAY_URLdefaults tohttps://relay:4443(WebTransport, ALPNh3) and there is no env knob to tell the relay which transport to serve. But the interop relay image defaulted to:MOQT_TRANSPORT=quic→ relay advertised only the rawmoqt-*ALPNs, so everyh3ClientHello was rejected withCRYPTO_ERROR 0x178 ... tls: no application protocol.MOQT_WEBTRANSPORT_PATH=/moq→ after fixing the ALPN, the client's path-less CONNECT targets/and 404s against the/moq-only handler.Both defaults assumed a configuration the harness never produces.
Fix
entrypoint-relay.sh+Dockerfile: defaultMOQT_TRANSPORT=webtransportandMOQT_WEBTRANSPORT_PATH=/to match the harness.main.go: skip the/catch-all 404 handler when the WebTransport path is/(registering two handlers on/panics the ServeMux; a root-mounted upgrade already covers everything). This makes-webtransport-path /work at all.The
-webtransport/-webtransport-path /moqbinary flag defaults are unchanged, so localgo run ./cmd/relayis unaffected — only the interop image defaults move.Verification
Reproduced the original failure through the runner's compose, then re-ran after the fix:
go build ./..., relay/wtconn tests, andgofmtall clean. This resolves the entire→ moq-gorelay column in the matrix (every client dialing a moq-go relay in docker), not just the self-test.Out of scope (peer-side, not moq-go bugs)
When moq-go is the docker client:
moq-go → moq-rs-draft-18/moq-dev-rstime out waiting for HTTP/3 settings (peer relays don't answer the WT dial), andmoq-go → aiomoqt-relayreportsserver didn't enable WebTransport(aiomoqt's H3 SETTINGS omit the WT-enable flagswebtransport-go's Dialer requires). Worth raising upstream; nothing to change here.🤖 Generated with Claude Code