1701829 - Firefox refuses to use HTTP/3 (QUIC) protocol, even if HTTP/3 (QUIC) is enabled and 0-RTT is disabled

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect, P2)

Description

[u673061]

Attachment: Screenshot showing that Firefox is still using HTTP/2

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0

Steps to reproduce:

1. Downloaded and installed Firefox Developer edition version 88.0b4
2. Nagivated to https://cloudflare-quic.com
3. The Cloudflare HTTP/3 (QUIC) test page shows that my browser is using HTTP/2
4. Refreshed the page several times (bypassing cache, by pressing Ctrl+Shift+R)
5. Set the preference network.http.http3.enable_0rtt to false
6. Went to about:serviceworkers to ensure that it is not a service workers issue.

Actual results:

The Cloudflare test page is still showing that my browser is using HTTP/2 despite doing the above tweaks and no service workers are registered.

Expected results:

The Cloudflare test page should show that my browser is using HTTP/3 (QUIC), and it should not change after refreshing and restarting.

Comment 1

[Kershaw Chang [:kershaw]]

Hi David,

Unfortunately, I can't reproduce this.
Could you try to get a http log?

Thanks.

Comment 2

[u673061]

I am very sorry, but the log file is too big for Bugzilla. May I upload it to Mega Drive?

Comment 3

[u673061]

The Mega link to the HTTP log file is https://mega.nz/file/zKhiCDJb#ecf0cM-LeagQHbXPEHJnq8NY77BWJLRrCMLbN50ueg0

Comment 4

[Kershaw Chang [:kershaw]]

Thanks for the log! It's really helpful.

The problem here is that the http3 connection is not ready within 50ms (defined in this pref network.dns.httpssvc.http3_fast_fallback_timeout), so we switch to use http2 connection.
I'd suggest to set network.dns.httpssvc.http3_fast_fallback_timeout to a larger value or set it to 0 for disabling it.

Comment 5

[Kershaw Chang [:kershaw]]

More context:

This bug is kinda regressed by bug 1697776. When the http3 connection is created because of HTTPS RR, we switched to use non-http3 connection unconditionally when the timer is triggered here. I think we should have a consistent behavior when HTTPS RR is not used, which is creating a backup connection and switch to the backup connection when it's ready to use.

Comment 6

[Kershaw Chang [:kershaw]]

Attachment: Bug 1701829 - Make sure we do fast fallback when h2 connection is ready, r=#necko

Comment 7

[u673061]

Update: Even if I set network.dns.httpssvc.http3_fast_fallback_timeout to 0 and 0-RTT disabled, the browser only connects via HTTP/3 to that page the first time; however when I refresh the page via Ctrl+Shift+R , it still uses HTTP/2

Comment 8

[Kershaw Chang [:kershaw]]

(In reply to David Hu from comment #7)

Update: Even if I set network.dns.httpssvc.http3_fast_fallback_timeout to 0 and 0-RTT disabled, the browser only connects via HTTP/3 to that page the first time; however when I refresh the page via Ctrl+Shift+R , it still uses HTTP/2

Could you capture another http log when network.dns.httpssvc.http3_fast_fallback_timeout is 0?
Thanks.

Comment 9

[u673061]

(In reply to Kershaw Chang [:kershaw] from comment #8)

(In reply to David Hu from comment #7)

Update: Even if I set network.dns.httpssvc.http3_fast_fallback_timeout to 0 and 0-RTT disabled, the browser only connects via HTTP/3 to that page the first time; however when I refresh the page via Ctrl+Shift+R , it still uses HTTP/2

Could you capture another http log when network.dns.httpssvc.http3_fast_fallback_timeout is 0?
Thanks.

Yeah. Sure: https://mega.nz/file/SDZFTKST#LjEoHBvpFS58Z6XBs9WML-3O9YcRg7FjyR9molRbVeM

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9b3b73f0e6f4
Make sure we do fast fallback when h2 connection is ready, r=necko-reviewers,dragana

Comment 11

[Kershaw Chang [:kershaw]]

(In reply to David Hu from comment #7)

Update: Even if I set network.dns.httpssvc.http3_fast_fallback_timeout to 0 and 0-RTT disabled, the browser only connects via HTTP/3 to that page the first time; however when I refresh the page via Ctrl+Shift+R , it still uses HTTP/2

I've looked at the log. The reason is that shift reloading kills the connection to the TRR server, so the HTTPS RR is not available at the point when Firefox is about to make a connection to cloudflare-quic.com.

Comment 12

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/9b3b73f0e6f4

Comment 13

[u673061]

The issue still persists on the latest nightly on the April 10 2021 version, should we reopen this?

Comment 14

[u673061]

Configurations:

network.dns.httpssvc.http3_fast_fallback_timeout	50	
network.http.http3.backup_timer_delay	100	
network.http.http3.default-max-stream-blocked	20
network.http.http3.default-qpack-table-size	65536	
network.http.http3.enable_0rtt	true	
network.http.http3.enable_qlog	true	
network.http.http3.enabled	true	
network.http.http3.recvBufferSize	1048576

Comment 15

[u673061]

Alexandru, thank you for the fix!
However, unfortunately it did not work on the latest Nightly.
It is possible that a regression occured.
Would you please take a look at the new HTTP logs attached in the following link when you are available?
It will be really appreciated.
Thank you!

Comment 16

[u673061]

Log link: https://mega.nz/file/mT4ilLCK#H0mubNqd0LpBagaQR65vsLUJpur9N_NydSwcft4qnBE

Comment 17

[u673061]

Environment: Firefox Nightly 89.0a1 (2020-04-10)

Comment 18

[Alexandru Michis [:malexandru]]

Hello David,
Kershaw is better suited than me to look at these HTTP logs.
I could backout the changes if they are causing regressions.

Comment 19

[Kershaw Chang [:kershaw]]

(In reply to David Hu from comment #16)

Log link: https://mega.nz/file/mT4ilLCK#H0mubNqd0LpBagaQR65vsLUJpur9N_NydSwcft4qnBE

Thanks for the log.
The log shows that TRR is not enabled, so the only way to connect to cloudflare-quic.com is using alt-svc header (as described here). This means the first connection to cloudflare-quic.com would be made via http2, since the alt-svc mapping is not available yet. After that, Firefox should be able to connect via http3. However, using shift reload (Ctrl+Shift+R) will clear the alt-svc mappings. That's why the connection is still made via http2.

Comment 20

[u673061]

So should we reopen this?

Comment 21

[Kershaw Chang [:kershaw]]

(In reply to David Hu from comment #20)

So should we reopen this?

No, I think this is the expected behavior. Note that there is no guarantee that Firefox should use http3 every time because:

1. Alt-svc header might not be available (Ctrl+Shift+R load clears the al-svc cache).
2. HTTPS RR is not available at the moment when Firefox is establishing the connection.

Comment 22

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Verified that the latest versions of Firefox 89.0b10 and Firefox 90.0a1 (2021-05-09) behaves as expected, as Kershaw mentioned in Comment 21. While clearing the cache (with ctrl+shift+r) the page is showing HTTP/2, and by normally refreshing the page, HTTP/3 is used everytime. Tests were performed on macOS 10.15.7, Ubuntu 20.04 and Windows 10.