search

quinn-rs / quinn

Async-friendly QUIC implementation in Rust
Apache License 2.0
3.85k stars 394 forks source link

WebTransport in Chrome throws ALPN error #1266

Closed Pascualex closed 2 years ago

Pascualex commented 2 years ago

I've checked this closed issue #934 and it looks like the problem persists.

Following the IETF draft specification I've set the "wq-vvv-01" ALPN in my server. Just to be completely sure, I've checked the values of my alpn_protocols and they are in fact the expected sequence: 0x77 0x71 0x2d 0x76 0x76 0x76 0x2d 0x30 0x31.

Chrome throws the following error: peer doesn't support any known protocol.

It isn't completely broken since when I don't specify any ALPN the error changes to: no application protocol.

I'm testing this with Chrome Beta, but version 97 will go out in January with WebTransport support, so this use case may start to be more common.

Ralith commented 2 years ago

That draft expired last January. It looks like the current WebTransport draft is draft-ietf-webtrans-http3, which builds on top of h3 rather than raw QUIC. Presumably Chrome is therefore using the h3 ALPN. If in doubt, wireshark should be able to tell you what ALPNs the client is offering.

Pascualex commented 2 years ago

I had tried a bunch of ALPNs, including h3-27, h3-29 and h3-32 but not the simple h3.

It's working now, thank you.

Ralith commented 2 years ago

Chrome throws the following error: peer doesn't support any known protocol.

Incidentally, this isn't actually a Chrome error, but a rustls error being piped all the way back down to the client. Pretty neat that that's being propagated gracefully!