Hi webtransport-dev,
I started looking at the current webtransport state by trying to run wpt, and I'm seeing a few odd things. I wanted to check where things stand and what's currently expected. Is this the right forum?
I don't think this is blocking me on what I'm looking into, but is there someone looking at the wpt behavior, if so is a report on this of interest to you, and do you need more information about the setup? Should I open a ticket for this, and if so against wpt or webtransport?
What I'm seeing:
I've got the server running in one ubuntu VM and the client running in another VM on the same host system. If I manually run chrome 98.0.4758.9, I see some quic traffic and some passed and one failed test in webtransport/connect.https.any.html:
KEY=$(cat tools/wptrunner/wptrunner/browsers/chrome_spki_certs.py | \
grep -E "^WPT_FINGERPRINT = " | \
sed -e "s/WPT_FINGERPRINT = '\([^']*\)'/\1/")
/usr/bin/google-chrome --ignore-certificate-errors-spki-list=${KEY} \
--origin-to-force-quic-on=web-platform.test:0 \
https://web-platform.test:8443/webtransport/connect.https.any.html
Passing --headless means no quic traffic goes to the server. Not sure if that's expected, and not sure what test results come out.
If I try running wpt, I see no UDP traffic to the server. I tried both with and without the "--origin-to-force-quic-on" passed with --binary-arg, and neither way got any traffic to the wpt server.
One time it claimed they all passed, but usually it claims there's one failed test, different from the one that fails from manually running:
./wpt run --binary=/usr/bin/google-chrome --binary-arg="--origin-to-force-quic-on=web-platform.test:0" --webdriver-binary=/usr/bin/chromedriver chrome webtransport/connect.https.any.html
Not sure why these all pass when no traffic comes to the server's vm, which is set up with the /etc/hosts entries from ./wpt make-host-file $SERVERIP on both the server and client, that seems unexpected to me.
Thanks,
Jake