moq-lite-05: add Path Setup Parameter for URI-less transports#27
Conversation
Native QUIC and Qmux-over-TCP/TLS negotiate only an ALPN token and have no request URI, so there is no way for a client to convey which path (origin/relay/virtual host) it wants to reach. Add a Path Setup Parameter (0x2) carrying an RFC3986 URI path, mirroring the PATH parameter from draft-ietf-moq-transport-18. It is client-only and required on the URI-less bindings (1 and 3), forbidden on the bindings that already carry the path in their handshake (WebTransport CONNECT URI, WebSocket request URI). Misuse and malformed paths are PROTOCOL_VIOLATION; an unsupported path closes the session. Relays do not forward it, consistent with other per-hop capabilities. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughThis pull request adds a Path Parameter capability to the MOQ Lite SETUP protocol. The change introduces a new mechanism for client-to-server communication of request paths in protocol bindings that do not define their own request URI (such as ALPN-only QUIC and Qmux over TCP/TLS). The implementation includes a normative reference to RFC3986, a parameter table entry defining Path as parameter ID 0x2 with string value type, and a complete specification section detailing encoding constraints, required presence/absence by binding type, error-handling behavior, and relay forwarding rules. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches✨ Simplify code
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
What
Adds a
PathSetup Parameter (0x2) to moq-lite, letting a client convey the request path it wants to reach (origin / relay / virtual host) at connection setup. Modeled on the PATH parameter from draft-ietf-moq-transport-18.Why
Two of moq-lite's four transport bindings — bare QUIC (binding 1) and Qmux-over-TCP/TLS (binding 3) — negotiate only an ALPN token and have no request URI. Without this parameter, a client on those transports has no way to indicate which path it wants, so a server cannot route the session before broadcasts are exchanged. The URI-bearing bindings (WebTransport's CONNECT path, WebSocket's request URI) already carry it in their handshake.
Details
0x2 | Path | Path (s)./([RFC3986], added as a normative reference).PROTOCOL_VIOLATION.PROTOCOL_VIOLATION.PROTOCOL_VIOLATION; unrecognized/unsupported path → session close. Uses moq-lite's existing generic error handling rather than introducing dedicatedINVALID_PATH/MALFORMED_PATHcodes.Reviewer notes
🤖 Generated with Claude Code