Add a QUIC server to test WebTransport

[Hexcles]

Note that this is not testing the protocol level, but a web API that builds on QUIC (similar to WebSocket): https://wicg.github.io/web-transport/

We had a discussion at TPAC today. We need a server binary because Python 2 lacks the necessary crypto primitives and there is also no good pure Python 3 implementation. There are two preferred server implementations, one in Go and the other in Rust. However, it is unfavourable to add compilation requirement to wpt, which is difficult for both browser infras and individual contributors.

In order to avoid having to compile code (server handlers) to run tests, the preferred path forward to experiment/prototype is:

• Pick a good, stable server and release the prebuilt binaries of it for various platforms. Teach WPT to download the correct binary (this will be similar to how we download webdrivers).
• Write custom handlers in Python in this repo, and establish a communication channel between the server binary and the Python handlers (pipe or local loopback connection to e.g. websocket).

cc @yutakahirano @ricea @jgraham : is this accurate?

[yutakahirano]

Yes, thank you.

[jugglinmike]

An alternative that wouldn't require managing binaries is to make a Python 3 implementation "good enough." That would also entail moving to Python 3--an undertaking unto itself, but one which we've previously recognized as valuable.

Probably this alternative is expected to be more challenging with what @Hexcles has proposed above, but since it isn't mentioned here or in the relevant TPAC 2019 meeting minutes, I thought it would be helpful to raise it and give the folks involved an opportunity to explain why it's not the best solution.

[Hexcles]

Thanks, @jugglinmike : yeah we did briefly discuss Python 3 migration prior to this discussion at TPAC and the short answer is "we want it and we agree on the path (six instead of Py3-only) but we don't have concrete plan or timeline", so it most likely won't happen in time for WebTransport. But yeah, if we have Python 3, we could make the pure Python 3 impl good enough and use it (we still probably want to avoid any library with native extensions).

[yutakahirano]

cc: @vasilvv

There are many things to do to migrate the entire wpt server to python3, but I guess it is much easier to install a python3 runtime and run a standalone server on it.

[yutakahirano]

Hi again (and sorry for the long silence).

Now we prefer having a python3 server. This option requires installing

• Python3 runtime
• Some native libraries

.

The main benefit compared to servers written in Rust/Go/... is that we don't need to invent a python interface to allow wpt authors to write QuicTransport protocol.

Python3 runtime is large, but given we will use it in any case, the marginal cost is small.

@Hexcles, @jugglinmike, is this option acceptable?

[jgraham]

There are still some difficulties moving everything over to Python 3. For gecko I think we could theoretically switch the project to pure Py3 tomorrow and there wouldn't be a problem. But I'm not sure that the same is true of Blink and (especially) WebKit.

So I think this option is easier, but we still need

• To actually do the work to migrate the rest of the infra to work with Python 3
• Some plan for how to handle scenarios where only Py2 is available (e.g. not running QUIC tests in those cases but continuing to run all other tests).

Also requiring native deps seems like it could have some of the same issues as requiring arbitrary Rust/Go code, depending on exactly what the deps are. Do you have details of the implementation you're looking at?

[Hexcles]

We can run a separate Python 3 server, no? python3 is available in Blink, too.

Some native libraries

Are you talking about Python native extensions? If so, it's probably not a huge problem. At least in Blink, we have mechanisms to manage those. I'd assume Gecko does, too?

[yutakahirano]

Yeah, I'm talking about having a separate server running on Python3. I'm not talking about migrating the existing web platform server to Python3.

[yutakahirano]

Friendly ping.

We would like to use https://github.com/aiortc/aioquic.

[Hexcles]

Sorry for the delay; I missed the ping when coming back from the holidays...

I took a look at aioquic. It has a native extension (for TLS stuff IIUC). Are we going to need that?

I don't think it'd be a big problem to have an optional standalone Python 3 server (even with a native extension). I think the path forward here will be what @jgraham said earlier: "Some plan for how to handle scenarios where only Py2 is available (e.g. not running QUIC tests in those cases but continuing to run all other tests)."

I'm imagining this setup:

• The Python 3 QUIC server will be standalone and behind a flag (we can discuss later whether it should be off by default, or on by default with an elegant error handling path).
• wpt serve will manage the lifecycle of the QUIC server as a subprocess, including port configurations: QUIC port(s) will still be configured in the same config file, and be passed to the QUIC server via command line.
• The QUIC server listens on the designated port(s) directly. (How many ports do we need for QUIC testing, btw?)

Does that sound good to you, @yutakahirano ? Also, does the QUIC server have any other special requirement? For example, for TLS, can it use the self-signed certs in tools/certs? Does it need new entries in /etc/hosts?

We should draft the design in the form of an RFC. I can help you with that.

[yutakahirano]

Thank you!

Does that sound good to you, @yutakahirano ?

Yes! I think only one port is enough.

Also, does the QUIC server have any other special requirement? For example, for TLS, can it use the self-signed certs in tools/certs? Does it need new entries in /etc/hosts?

According to the readme we can use cert files. I guess we can do that for QuicTransport too.

$ python examples/http3_server.py --certificate tests/ssl_cert.pem --private-key tests/ssl_key.pem

We should draft the design in the form of an RFC. I can help you with that.

Thank you, I'll look into the document.

[Hexcles]

RFC is posted at web-platform-tests/rfcs#42

Sorry for the delay.

[yutakahirano]

Thank you!

[stephenmcgruer]

What is the status of this issue? The QUIC RFC and server landed long ago; are we done here @yutakahirano / @Hexcles .

If not what are the concrete steps left to close this out?

[Hexcles]

The server has been "added", but not enabled by default, which is still blocked by finalizing the API design w3c/webtransport#125

Shall we close this one and open a new issue for enabling QUIC by default?

[stephenmcgruer]

No that's fine, this can just stay and be blocked on w3c/webtransport#125 - as long as we know the next steps

[yutakahirano]

I think now it's unblocked. @jan-ivar

[jan-ivar]

@Hexcles This should be unblocked now.

[foolip]

This was done in https://github.com/web-platform-tests/rfcs/blob/master/rfcs/webtransport_h3_test_server.md.