How to test Web Transport port to WASM

[guest271314]

I read this

picoquic/doc/pico_webtransport.md

Lines 62 to 66 in d399d3a

	* Prepare a picoquic context ready to accept HTTP3 requests. In `picoquicdemo`,
	this is done by setting the callback to `picoquic_demo_server_callback`,
	defined in `demoserver.c`. That callback provides support for 4 different
	protocols: HTTP3, HTTP/0.9, SIDUCK and QUICPERF. If you only want to support
	HTTP3, you can set the callback function to `h3zero_callback`, defined in `

Prepare a picoquic context ready to accept HTTP3 requests. In picoquicdemo,
this is done by setting the callback to picoquic_demo_server_callback,
defined in demoserver.c. That callback provides support for 4 different
protocols: HTTP3, HTTP/0.9

and am trying to understand how that works. My novice understand is that WebTransport required HTTP/3.

What I'm actually trying to do is port a WebTransport server implementation to JavaScript or compile to WASM to I can create a WebTransport server in Chromium browser over Direct Sockets UDPSocket.

[huitema]

There is no such thing as QUIC over HTTP/0.9. It is the other way around. During the early tests of the QUIC transport protocol, the QUIC working group adopted HTTP/0.9 as an example of application running over QUIC. That was back in 2017, while HTTP3 was very much a work in progress.

Multiple application protocols can run over QUIC. They are identified by the ALPN parameter of the TLS session that is negotiated during the QUIC handshake. HTTP3 uses ALPN="h3"; HTTP/0.9 uses ALPN="hq-interop".

You can find an example of web transport server running above picoquic in the "baton" sample.

[guest271314]

@huitema

I would be interested to see the results if you try that.

Alright, I'll try then. So far I've tried

• Compile fails-components/webtransport (depends on quiche compiled to a .node file) Can this library be used with WICG Direct Sockets for a WebTransport server? fails-components/webtransport#354 which consistently got stuck on protobuf usages and then after then still have to deal with the .node file
• Rust's quinn compiled to WASM, following up on the work by @maceip https://github.com/guest271314/quinn-wasm/tree/direct-sockets
• Asked about compiling BiagioFesta/wtransport to WASM Can the server be compiled to JavaScript for use in Deno? BiagioFesta/wtransport#40
• Asked about compiling quiche to WASM Has anybody compiled quiche to WASM? google/quiche#86
• quico https://github.com/colocohen/quico (Node.js which I plan(ned) to convert to Web API's)
• Currently days upon days of trying to get Google's Gemini to implement a WebTransport server in JavaScript https://gemini.google.com/share/a34176ee9792, which not infrequently freezes the browser tab; I sense I'm close, just need to complete the TLS handshake, I think

[guest271314]

What specifically is the most minimal WebTransport server build roadmap?

[guest271314]

I would be interested to see the results if you try that.

First try with WASI-SDK

cmake -DCMAKE_TOOLCHAIN_FILE=${WASI_SDK_PATH}/share/cmake/wasi-sdk-pthread.cmake -DCMAKE_C_COMPILER=/media/user/x/wasi-sdk/bin/clang -DCMAKE_CXX_COMPILER=/media/user/x/wasi-sdk/bin/clang++ .
-- The C compiler identification is Clang 20.1.8
-- The CXX compiler identification is Clang 20.1.8
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /media/user/x/wasi-sdk/bin/clang - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /media/user/x/wasi-sdk/bin/clang++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Initial CMAKE_C_FLAGS= -pthread -pthread
CMake Error at /usr/share/cmake-3.31/Modules/FindPackageHandleStandardArgs.cmake:233 (message):
  Could NOT find PTLS (missing: PTLS_CORE_LIBRARY PTLS_OPENSSL_LIBRARY
  PTLS_MINICRYPTO_LIBRARY PTLS_INCLUDE_DIR)
Call Stack (most recent call first):
  /usr/share/cmake-3.31/Modules/FindPackageHandleStandardArgs.cmake:603 (_FPHSA_FAILURE_MESSAGE)
  cmake/FindPTLS.cmake:64 (find_package_handle_standard_args)
  CMakeLists.txt:282 (find_package)


-- Configuring incomplete, errors occurred!

[huitema]

The picoquic code links with the "picotls" library (see Cmake), which itself has a dependency on openSSL.

[guest271314]

So, an inkling of a roadmap to get openSSL in the compiliation would be what?

[huitema]

Did you read the documentation in pico_webtransport.md?

[guest271314]

No. Didn't see that. I got the repository using git. In the repository on the command line what specific commands to run to build the simplest WebTransport (echo) server?

[huitema]

There is no code yet for the echo sevrer, but there is code for the "devious baton" test -- just build everything and look for the "baton_app", which has both client and server modes.

[guest271314]

Looks like the executable name is pico_baton.

I tried this

$ ./pico_baton -p 3000 -k ./key.pem -c ./cert.pem /baton
No token file present. Will create one as <baton_token_store.bin>.
Starting a baton server.Waiting for packets.

and this in Chromium browser DevTools, after generating a self-signed certificate, and writing the private key and certificate to cert.pem and key.pem

/*
  ~/firefox/firefox-bin -headless -P wt wt-client.html 2>&1 | node -e '(async()=>{const decoder=new TextDecoder;for await (const data of process.stdin){const result=decoder.decode(data).match(/console.log:.+(?=\n)/);if(result){console.log(result[0]);if(result[0].includes("closeCode")){require("child_process").exec("pkill -f \"firefox-bin -headless\"");process.exit();}}}})()'
  ~/chrome-linux/chrome --headless --enable-logging=stderr --disable-gpu --password-store=basic wt-client.html 2>&1 | grep WEBTRANSPORT_CLIENT
  node --no-warnings wt-client.js
  bun --no-warnings wt-client.js
  DENO_COMPAT=1 deno -A wt-client.js
*/
;(async () => {
  globalThis.WT_CLIENT = `WEBTRANSPORT_CLIENT: `;
  const CERT_DIGEST = new Uint8Array([235,74,246,224,84,32,108,38,238,188,232,225,129,231,27,168,223,115,172,237,47,197,60,44,245,32,39,37,103,30,224,247]);
  try {
    const serverCertificateHashes = [
      {
        "algorithm": "sha-256",
        "value": CERT_DIGEST,
      },
    ];
    if (!Object.hasOwn(globalThis, "WebTransport")) {
      let { WebTransport, quicheLoaded } = await import(
        "./webtransport-client-bundle.js"
      );
      await quicheLoaded;
      globalThis.WebTransport = WebTransport;
    }
    const client = new WebTransport(
      `https://127.0.0.1:3080/baton?count=17`,
      {
        serverCertificateHashes,
      },
    );

    await client.ready;
    console.log(`${WT_CLIENT}WebTransport client ready.`);

    const { readable, writable } = await client.createBidirectionalStream();
    let data = new Uint8Array(1024 ** 2 * 20);

    let header = new Uint8Array(Uint32Array.from(
      {
        length: 4,
      },
      (_, index) => (data.length >> (index * 8)) & 0xff,
    ));
    let view = new DataView(header.buffer);
    let outgoingTotalLength = view.getUint32(0, true);
      console.log(`${WT_CLIENT}${JSON.stringify({outgoingTotalLength})}`);
    let incomingTotalLength = 0;
    const writer = writable.getWriter();
    await writer.ready;
    await writer.write(header).then(() =>
      console.log(
        `${WT_CLIENT}Outgoing total length ${outgoingTotalLength} written.`,
      )
    );
    await writer.ready;

    await writer.write(data)
      .then(() => console.log(`${WT_CLIENT}${data.length} bytes written.`))
      .catch((e) => {
        console.log(`${WT_CLIENT}${e.message}`);
      });

    await writer.ready;
    await writer.close();
    for await (const value of readable) {
      incomingTotalLength += value.length;
      if (incomingTotalLength === outgoingTotalLength) {
        console.log(
          `${WT_CLIENT}${
            JSON.stringify({ incomingTotalLength, outgoingTotalLength })
          }`,
        );
        break;
      }
    }
    client.close({ closeCode: 4999, reason: "Done streaming." });
    return await client.closed
      .then((result) => console.log(`${WT_CLIENT}${JSON.stringify(result)}`))
      .catch((e) => {
        console.log(`${WT_CLIENT}${e.message}`);
      });
  } catch (e) {
    console.log(`${WT_CLIENT}${e.message}`);
  }
})()
  .catch((e) => {
    console.log(`${WT_CLIENT}${e.message} "closeCode":0`);
  })
  .finally(() => /Headless|Deno/.test(navigator.userAgent) && (globalThis?.process?.exit() || globalThis?.close && close()));

Failed to establish a connection to https://127.0.0.1:3080/baton: net::ERR_CONNECTION_REFUSED.
VM191:83 WEBTRANSPORT_CLIENT: Opening handshake failed.

That's what I use here https://github.com/guest271314/webtransport-js-bundle/blob/main/wt-client.js to test WebTransport servers and clients.

[guest271314]

There is no code yet for the echo sevrer, but there is code for the "devious baton" test -- just build everything and look for the "baton_app", which has both client and server modes.

What is pico_baton expecting from the client?

[guest271314]

Ah, I was using the incorrect port in wt-client.js. I get past the handshake with this

 const client = new WebTransport(
      `https://127.0.0.1:3000/baton`,
      {
        serverCertificateHashes,
      },
    );

This is logged to console

WEBTRANSPORT_CLIENT: WebTransport client ready.
VM847:46 WEBTRANSPORT_CLIENT: {"outgoingTotalLength":20971520}
VM847:51 WEBTRANSPORT_CLIENT: Outgoing total length 20971520 written.
VM847:60 WEBTRANSPORT_CLIENT: The session is closed.
VM847:83 WEBTRANSPORT_CLIENT: The session is closed.

I don't know what this means

user@debian:/media/user/86af3b7b-78ec-45e7-8a6f-299cd3d770e4/picoquic$ ./pico_baton -p 3000 -k ./key.pem -c ./cert.pem -w -l=- /baton
No token file present. Will create one as <baton_token_store.bin>.
Starting a baton server.Waiting for packets.
!.!!.!.!.....................................................................................!!..........!.!....!.........!.!.!.!.........................................................................!.!!.!.!......................................................................................................................!..........!.........!..............................................................................................................................................!!.....!.!!.!..!.!............................

[huitema]

You cannot test web transport by itself, no more that you could test TCP by itself. You are always testing an application protocol running on top of web transport. The "devious baton" protocol was developed by Alan Frindell to test web transport implementation, and is specified in this Internet draft.

When testing on a browser, you need to have a javascript implementation of the application. There is one available on Github.

[guest271314]

I changed the URL and use the digest from the self-signed certificate I generated.

[guest271314]

That's from Chromium Version 147.0.7700.0 (Developer Build) (64-bit) tip-of-tree snapshot from today.

Here's Firefox Nightly 149.0a1 (2026-02-22) (64-bit) from today

[guest271314]

I've got some stuff to do, then I'll try to compile pico_baton to WASM with LLVM's clang and WASI-SDK's clang. Then I'll go back to trying to get my actual use case: Direct Sockets UDPSocket => pico_baton to handle handshake and decrypt raw data as Uint8Array => pass raw data as Uint8Array to pico_baton for encryption to QUIC packet => write encrypted QUIC packet back to UDPSocket.

[guest271314]

If I can get the code to WASM I can get the code to JavaScript via wasm2js.

[guest271314]

You are always testing an application protocol running on top of web transport.

FYI the protocol I use to test WebTransport in my code above is the Native Messaging protocol, see https://github.com/guest271314/NativeMessagingHosts?tab=readme-ov-file#native-messaging-documentation.

I've have to figure out a way to just use your library for handshake and data processing, and that's it, and get rid of however the UDP socket is created, substitute with UDPSocket https://wicg.github.io/direct-sockets/#udpsocket-interface.

[huitema]

For some reason, Github is not displaying your last comments into this thread. I received the corresponding email, but the messages just do not show in the web interface.

From what I read on the mail, your WASM attempt failed because you needed to also include picotls in the build, and that by default picotls has a dependency on OpenSSL. You can work around that in two ways:

1- Set an argument to CMake to fetch and include picotls as a component: -DPICOQUIC_FETCH_PTLS=Y
2- Set an argument to CMake to compile picotls without OpenSSL: -DWITH_OPENSSL=OFF

Not using OpenSSL has a cost. The build will fallback to the minicrypto modules included in picotls, which have some significant limitations:

• The server can only use certificates with ECDSA keys
• The only supported encryption modules are AES256, AES384 and ChaChaPoly
• The implementation of the AES algorithms does not use hardware acceleration and is thus really slow
• There is no certificate verification code available on the client

However, since everything is compiled from code, your WASM assembly ought to be complete.

[guest271314]

Neither works.

cmake -DCMAKE_TOOLCHAIN_FILE=${WASI_SDK_PATH}/share/cmake/wasi-sdk-pthread.cmake -DCMAKE_C_COMPILER=/media/user/x/wasi-sdk/bin/clang -DCMAKE_CXX_COMPILER=/media/user/x/wasi-sdk/bin/clang++ -DPICOQUIC_FETCH_PTLS=Y .
-- The C compiler identification is Clang 20.1.8
-- The CXX compiler identification is Clang 20.1.8
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /media/user/x/wasi-sdk/bin/clang - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /media/user/x/wasi-sdk/bin/clang++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Initial CMAKE_C_FLAGS= -pthread -pthread
-- Detecting USDT support
-- Detecting USDT support - disabled on this platform
-- Detecting fusion support
-- Cannot use fusion
-- Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the system variable OPENSSL_ROOT_DIR (missing: OPENSSL_CRYPTO_LIBRARY OPENSSL_INCLUDE_DIR) 
CMake Warning at _deps/picotls-src/CMakeLists.txt:177 (MESSAGE):
  Disabling OpenSSL support (requires 1.0.1 or newer)


-- picotls/include: /media/user/x/picoquic/_deps/picotls-src/include
-- picotls libraries: picotls-core;picotls-openssl;picotls-minicrypto
-- PTLS compiled without support for Fusion
-- Building without picotls-openssl
-- Defining picoquic-core
-- mbedtls/include: 
CMake Error at CMakeLists.txt:623 (install):
  install TARGETS given target "picotls-openssl" which does not exist.


-- Project version: 0.0.0-d399d3a0
-- Configuring incomplete, errors occurred!

cmake -DCMAKE_TOOLCHAIN_FILE=${WASI_SDK_PATH}/share/cmake/wasi-sdk-pthread.cmake -DCMAKE_C_COMPILER=/media/user/x/wasi-sdk/bin/clang -DCMAKE_CXX_COMPILER=/media/user/x/wasi-sdk/bin/clang++ -DWITH_OPENSSL=OFF -DPICOQUIC_FETCH_PTLS=N .
-- Initial CMAKE_C_FLAGS= -pthread
CMake Error at /usr/share/cmake-3.31/Modules/FindPackageHandleStandardArgs.cmake:233 (message):
  Could NOT find PTLS (missing: PTLS_CORE_LIBRARY PTLS_OPENSSL_LIBRARY
  PTLS_MINICRYPTO_LIBRARY PTLS_INCLUDE_DIR)
Call Stack (most recent call first):
  /usr/share/cmake-3.31/Modules/FindPackageHandleStandardArgs.cmake:603 (_FPHSA_FAILURE_MESSAGE)
  cmake/FindPTLS.cmake:64 (find_package_handle_standard_args)
  CMakeLists.txt:282 (find_package)


-- Configuring incomplete, errors occurred!

[huitema]

Sorry, I was not clear. You need both options: -DPICOQUIC_FETCH_PTLS=Y and -DWITH_OPENSSL=OFF

[huitema]

You want to port picoquic to the WASM architecture, and you want at the same time to use a test service (echo) that is not supported in the current build. As a first step, I would drop the "use echo for test" requirement, and just do the tests using the built in "baton" app.

1- compile picotls using CMake options to not include a dependency on OpenSLL, but only use the minicrypto library. You will know this works when the compile works. You may want to also compile and run the tests in the WASM environment, to check that you have all the dependencies. There may be a need to

2- provide an implementation of an equivalent to void* picoquic_packet_loop_v3(void* v_ctx) (see sockloop.c): that's the default implementation of the "networking API" in picoquic. It uses sockets and select(); you will need to replace that by the equivalent in the WASM environment. Add that as a C file in the picoquic folder.

3- provide a CMake option and a compile option to make sure that the picoquic-core library is built using only the "minicrypto" library is picotls, that your version of picoquic_packet_loop_v3, and that sock_loop.c and picosocks.c are not included in the build when compiling for WASM.

That should allow you to build the baton app in WASM. You should then be able to test it.

I suspect that we will find something issues along the way. There may be an issue with stdio, and that means we may have disable logging options in the build. You might need to do something with the configuration functions, which today parse command line arguments.

[guest271314]

I see... I'll try to parse those instructions and build something.

[huitema]

Reading back what I wrote, I am not so sure we need to change CMake...

We want to treat WASM as "another platform on which picoquic can be compiled." For other platforms, e.g., ESP32, we have done that by using compile directives, e.g. #ifndef ESP_PLATFORM. We probably want to do something similar with something like __WASM__ (see code overflow page. So we could have an iterative process: try to compile, find what breaks, use #ifdef __WASM__ to provide alternative code.

Regarding the report on not finding OpenSSL:

Could NOT find PTLS (missing: PTLS_CORE_LIBRARY PTLS_OPENSSL_LIBRARY
  PTLS_MINICRYPTO_LIBRARY PTLS_INCLUDE_DIR)

That's a bug! The application is compiled "without openssl". The finder should not search for the openSSL library. We should fix that.

[guest271314]

Yeah, now you remind me of that... I havn't even started trying to follow those instructions, yet. I've dealt with CMake before with fails-components/webtransport.

To me, it should be simple to separate the QUIC state machine part from I/O. Evidently not.

[guest271314]

The original JavaScript server code for JavaScript was a POC that demonstrated a single connection. I've been working on at least serving connections in succession. I think I have that pattern now. The client WebTransport.close() doesn't propagate, or I havn't found out where it's fired, so I've been using writer.close() where FIN is sent for the stream, to close the session. Repeat.

[huitema]

Opened issue #2076 to track the CMake issue when building without OpenSSL.

[huitema]

@guest271314 -- Can you please check PR #2077? It is an update to the PTLS finder used when building picoquic. The update is to trim the dependency lists and the returned set of libraries, to not include openssl dependencies. It should solve the "Could NOT find PTLS" issue that you encountered.

[guest271314]

I think WASM world has a libc. I'll look around.

[guest271314]

Something like this https://github.com/webassembly/wasi-libc?

You know, it occurred to me that I could take the existing working WASM I have and port it to C with wasm2c. In theory this should compile, though I havn't tested re-compilation, yet.
quic.zip

[guest271314]

I think I need to pass that sysroot option to WASI-SDK's clang.

[guest271314]

Wait a minute. I did pass that, here

cmake -DCMAKE_TOOLCHAIN_FILE="${WASI_SDK_PATH}/share/cmake/wasi-sdk.cmake" 

[guest271314]

No results for this https://github.com/search?q=repo%3AWebAssembly%2Fwasi-libc+bits%2Flibc-header-start.h&type=code