Add WebTransport support

[Pascualex]

It would be useful to support WebTransport now that it is getting released in Chrome 97.

After looking into it, some additional work seems to be required to enable this support.

The Session Establishment section of the draft defines some required settings for the settings frame. I've been experimenting a bit but I'm still stuck with a net::ERR_METHOD_NOT_SUPPORTED and an unsuccessful handshake.

I'm not sure if after achieving a successful handshake there will be additional work required to support this protocol.

I'm using aioquic as a reference, since that is the library that Chrome is using to support their example WebTransport server.

It looks like Neqo has also added WebTransport support.

[stammw]

Hi @Pascualex,

I wanted to come up with an exhaustive list of what's missing in this crate to support WebTransport. But with the holidays I actually don't have much time for this. So here are some points I found, which will make the WebTransport implementation a non-trivial work:

• Custom Settings, namely for SETTINGS_ENABLE_WEBTRANSPORT.
• CONNECT method has to be implemented.
• Bidirectionnal stream from server
• Custom stream types
• Custom frame types
• Custom Error codes
• HTTP Datagrams

Neqo seems to implement directly web-transport into their http3 crate, but as h3 goal is to be highly reusable for a variety of use cases, we might want to implement some of these features in a separate crate and offer an extensibility methods within h3. (I assume the main goal of Neqo is to offer the http3 in Firefox only).

We could also implement WebTransport with feature-gated code within h3. But the extensibility seems a rather future-proof approach for other public or vendor protocol extensions.

Nevertheless, I think we'll concentrate on this starting at v0.2 the soonest. If your keen to help us you are more than welcome! :)

[Pascualex]

Hi @stammw,

Thanks for looking into it. I agree that this should not be part of the core of H3 and that it makes sense to delay this until the core is released.

To be honest with you what I know of these protocols is mostly from a user perspective, but if there is something I can help with I'll gladly do it.

[zhenzhu478]

Hi @Pascualex,

I wanted to come up with an exhaustive list of what's missing in this crate to support WebTransport. But with the holidays I actually don't have much time for this. So here are some points I found, which will make the WebTransport implementation a non-trivial work:

• Custom Settings, namely for SETTINGS_ENABLE_WEBTRANSPORT.
• CONNECT method has to be implemented.
• Bidirectionnal stream from server
• Custom stream types
• Custom frame types
• Custom Error codes
• HTTP Datagrams

Neqo seems to implement directly web-transport into their http3 crate, but as h3 goal is to be highly reusable for a variety of use cases, we might want to implement some of these features in a separate crate and offer an extensibility methods within h3. (I assume the main goal of Neqo is to offer the http3 in Firefox only).

We could also implement WebTransport with feature-gated code within h3. But the extensibility seems a rather future-proof approach for other public or vendor protocol extensions.

Nevertheless, I think we'll concentrate on this starting at v0.2 the soonest. If your keen to help us you are more than welcome! :)

Hi,
Any update about these features?

[darioalessandro]

Hi friends:

I will take on the job of building a POC.

I already added webtransport support to web apps written in rust via wasm-bindgen: rustwasm/wasm-bindgen#3344

Reddit demanded it: https://www.reddit.com/r/rust/comments/11rfes0/comment/jc8kyax/?utm_source=share&utm_medium=web2x&context=3

[darioalessandro]

I am happy to inform that we have a working prototype

Screen.Recording.2023-04-01.at.10.03.42.PM.mov

[amytimed]

It has been 2 weeks, what is the progress

[seanmonstar]

It is an exciting feature, I can see why you'd want to use it. But, please don't ask in a status-tracking issue for status updates. We keep the issue updated with the latest already, and asking can cause stress on contributors as if they somehow aren't working fast enough in their volunteer time.

[darioalessandro]

It has been 2 weeks, what is the progress

Hey @AmySour thanks for caring!

If you check out the PR and run the sample webtransport echo server, you'll see the datagrams API in action, as well as client initiated unistreams. @ten3roberts and I are working hard to finish this for the community quickly while also ensuring we don't create technical debt.

The main challenge is that h3 is meant to abstract the quic connection as much as possible, whereas webtransport interacts directly with it.

Rest assured, we'll have good news soon!

[ten3roberts]

Well put.

What we have:

• Session negotiation
• Single Session establishing through connect
• Incoming uni streams
• Incoming bi streams (send/recv)
• Reading datagrams
• Sending datagrams
• Buffer according to spec

The implementation has low overhead as it essential targets the quic streams almost directly.

For example, when a bistream is received it can be either an HTTP request, or a special frame indicating it is a Webtransport stream.

This "frame" has no length, so when it is received the framed decoder (which is still needed in case it is a "normal" frame stream) is unwrapped, and the rest of the data is read streaming.

The difficulties have been in adapting the internal traits to work with this low level use, as well as changing the direct plumbing now when more types can be received.

[seanmonstar]

Feedback welcome in this discussion about where the code should live: #189