Closed Bug 1683261 Opened 4 years ago Closed 4 years ago

HTTP/3 protocol enabled, but quic.rocks says I'm using HTTP 1.1

Categories

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

Unspecified
Android
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: ekager, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-triaged])

From github: https://github.com/mozilla-mobile/fenix/issues/15039.

On Firefox 81.1.0-beta.2 (Build #2015761657) if from about:config network.http.http3.enabled was set to true, Firefox should use HTTP/3 on all sites that supports it. I tried https://quic.rocks:443/. The results showed that I was using HTTP/1.1. However refreshing the page showed that I was using HTTP/3. Going to about:config and toggling security.ssl3.ecdhe_rsa_aes_256_gcm_sha384 to true seemed to show HTTP/3 enabled on quick.rocks on every page refresh, and even new loads. However, toggling this to false again shows the HTTP/1.1 page and on refresh showed HTTP/3.

Note

From about:config, I had all security.ssl3.* set to false except for any rules containing poly, gcm, chacha, these were set to true. I tried experimenting with security.ssl3.rsa_aes_256_gcm_sha384(notice the absence of ecdhe) and toggling that to false and reloading https://quic.rocks, and it leads me with an error page, Address not found which is acceptable and just throwing it out there. I also had network.trr.mode set to 3 and esni enabled.

First time loading with security.ssl3.ecdhe_rsa_aes_256_gcm_sha384 set to true, network.http.https.enabled set to true

First time loading with security.ssl3.ecdhe_rsa_aes_256_gcm_sha384 set to false

Device: Samsung
Android Version: 10

Change performed by the Move to Bugzilla add-on.

Component: General → Networking: HTTP
Product: GeckoView → Core
Blocks: QUIC
Severity: -- → S4
Priority: -- → P3
Whiteboard: [necko-triaged]

I think that this is invalid.

The enabling or disabling of the cipher suite had no effect for me. In terms of cipher suites, the server appears to favour a different cipher (ChaCha20Poly1305) when negotiating QUIC, but this is not the cause of the observed behaviour.

What is happening - at least for me - is the the initial page load uses HTTP/1.1. That is where we receive the Alt-Svc information that allows us to enable QUIC for the site. However, as this is an alternative service, we don't reload the page. It is only when the page is reloaded that we use QUIC. A hard reload (holding shift, say) will clear this state and we will end up using HTTP/1.1 again.

Everything seems to be working fine from my perspective.

We are performing some actions when security prefs change, but we do not clean up Alternative service cache. I have double check that.

I will mark this as invalid. The original github issue is old and meanwhile the code has been improved.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME

mt, thanks for testing it!

You need to log in before you can comment on or make changes to this bug.