http3 server in mochitests does not support locations from build/pgo/server-locations.txt
Categories
(Core :: Networking, defect, P2)
Tracking
()
People
(Reporter: robwu, Assigned: kershaw)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
(Whiteboard: [necko-triaged])
Short version:
When I run a mochitest with --use-http3-server, the test fails if it relies on anything other than https://mochi.test:8888, https://example.com or https://example.org. It seems that these are listed in the initial patch for bug 1809843, at build/pgo/certs/mochitest-cert.certspec. These few server names are not enough. There are many more https:-locations in build/pgo/server-locations.txt that are relied upon by mochitests. Expanding the list of domains would allow the removal of many skip-if = http3 from test manifests (and also avoid backouts of patches due to http3 test failures, which is why I started investigating this).
Detailed analysis
I observed a backout of my patch at https://bugzilla.mozilla.org/show_bug.cgi?id=1825824#c5 because the new test fails on M-http3. The test gets stuck at the part where it tries to load https://example.net - https://hg.mozilla.org/integration/autoland/rev/013b29254435#l3.100
I get the following log when I run the test on a debug build, with ./mach test toolkit/components/extensions/test/mochitest/test_ext_dnr_other_extensions.html --tag=remote-webextensions --headless --compare-preferences --log-mach-verbose --use-http3-server:
0:21.87 INFO add_task | Entering tabs_create_can_be_redirected_by_other_dnr_extension
0:21.88 INFO Extension loaded
0:22.04 INFO Extension loaded
0:22.22 INFO Waiting for navigation done, starting from https://example.net/?dnr_redir_me_pls
0:22.24 GECKO(59877) [WARN neqo_crypto::agent] [Agent 0x10d479490] error: NssError { name: "SSL_ERROR_HANDSHAKE_FAILED", code: -12116, desc: "SSL handshake has already failed. No more operations possible." }
Note the error in the end... After some trial and error with other tests, it seems apparent that the https3 test server only supports https://mochi.test:8888, https://example.com and https://example.org. I found these additional URLs by running ./mach test toolkit/components/extensions/test/mochitest/test_ext_exclude_include_globs.html --tag=remote-webextensions --headless --compare-preferences --log-mach-verbose --use-https3-server, because that fails ultimately, but not before showing some successful loads:
0:13.93 TEST_START: toolkit/components/extensions/test/mochitest/test_ext_exclude_include_globs.html
0:17.00 INFO add_task | Entering test_contentscript
0:17.01 INFO Extension loaded
0:17.05 INFO extension loaded
0:17.10 GECKO(60228) Console message: [JavaScript Warning: "Storage access automatically granted for origin “https://example.org” on “https://mochi.test:8888”."]
0:18.13 GECKO(60228) Console message: [JavaScript Warning: "This page is in Quirks Mode. Page layout may be impacted. For Standards Mode use “<!DOCTYPE html>”." {file: "https://example.org/" line: 0}]
0:18.30 PASS undefined assertion name
0:18.43 GECKO(60228) Console message: [JavaScript Warning: "Storage access automatically granted for origin “https://test1.example.org” on “https://mochi.test:8888”."]
test gets stuck here, i.e. test1.example.org did not load
The log above shows that https://example.org was successfully loaded. And indeed, when I change example.net to example.org in the failing test from bug 1825824, the test passes with https3.
The "working" domains are listed in the patch from bug 1809843 at https://hg.mozilla.org/mozilla-central/rev/8699a91328fc380d567ce028e28014ff1965d992#l8.3. That seems not a coincidence...
|
||
Updated•2 years ago
|
|
|
||
Updated•2 years ago
|
|
Assignee | |
Comment 1•1 years ago
|
||
Assign this to myself.
Also, this bug doesn't affect users. So, I think we can downgrade this.
|
Reporter | |
Updated•1 years ago
|
|
|
Assignee | |
Comment 2•1 year ago
|
||
This is fixed by bug 1829152.
|
|
Reporter | |
Comment 3•1 year ago
|
||
I intended to cover more than just example.net with this report. In the report, I linked the server-locations.txt file that lists all relevant host names.
Rather than playing whack-a-mole with one domain at a time, I was hoping for this bug to be resolved by listing all knowingly relevant host names in the cert spec of the h3 server. Can this bug be reopened and that be done?
(Or are you intentionally trying to keep the list minimal?)
|
|
Assignee | |
Comment 4•1 year ago
|
||
Please take a look at this patch.
I'd like to make the server support the following domains:
mochi.test,example.com,*.example.com,example.net,*.example.net,example.org,*.example.org
I hope it's enough.
|
|
Reporter | |
Comment 5•1 year ago
|
||
When I take the existing locations, omit the parts that a distinct certificate or special behavior, and then drop the existing 3 example domains, I get the following hosts that are currently not covered by the changes proposed thus far:
$ curl -s https://hg.mozilla.org/mozilla-central/raw-file/tip/build/pgo/server-locations.txt | grep ^https: | grep -vE cert=\|redir=\|failHandshake\|nocert | cut -d' ' -f1-1 | grep -vE '(/|\.)example\.(net|org|com)'
https://127.0.0.2:443
https://www.itisatrap.org:443
https://xn--hxajbheg2az3al.xn--jxalpdlp:443
https://sub1.xn--hxajbheg2az3al.xn--jxalpdlp:443
https://itisatracker.org:443
https://fpdownload2.macromedia.com:443
https://w3c-test.org:443
https://www.w3c-test.org:443
https://www1.w3c-test.org:443
https://www2.w3c-test.org:443
https://xn--n8j6ds53lwwkrqhv28a.w3c-test.org:443
https://xn--lve-6lad.w3c-test.org:443
https://mochitest.youtube.com:443
https://localhost:443
... or the following highlighted lines (including comments):
https://searchfox.org/mozilla-central/rev/11dbac7f64f509b78037465cbb4427ed71f8b565/build/pgo/server-locations.txt#135-137,140-141,143,155-156,196,233-237,285-291,336-337,339-340
(the fpdownload2.macromedia.com one seems obsolete, as Flash is dead)
Description
•