Add telemetry for alpn mismatch
Categories
(Core :: Networking, task, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox136 | --- | fixed |
People
(Reporter: valentin, Assigned: valentin)
References
Details
(Whiteboard: [necko-triaged])
Attachments
(1 file)
We should have a probe to check how often we get a ALPN mismatch that causes us to reset the connection.
|
Assignee | |
Comment 1•1 year ago
|
||
|
||
Comment 4•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/75d88db50aea
https://hg.mozilla.org/mozilla-central/rev/09e64054344b
|
|
Assignee | |
Comment 5•11 months ago
|
||
on beta we see a few thousand clients recording a mismatch, which is probably 1-2% of users.
Kershaw, what do you think our next steps should be?
|
||
Comment 6•11 months ago
|
||
(In reply to Valentin Gosu [:valentin] (he/him) from comment #5)
on beta we see a few thousand clients recording a mismatch, which is probably 1-2% of users.
Kershaw, what do you think our next steps should be?
The majority of data seems to indicate that NegotiatedNPN is empty. Looking at the code, it's possible that we intentionally set NegotiatedNPN to an empty value. I wonder if this is due to the lack of support for the ALPN extension by some servers.
Dana, do you know why NegotiatedNPN is empty? If it is empty, can we assume it's an HTTP/1.1 connection?
Thanks.
|
||
Comment 7•11 months ago
|
||
If it's empty, it should be because it wasn't negotiated, but it looks like we're not handling the 0-RTT case (SSL_NEXT_PROTO_EARLY_VALUE). I doubt that would account for the majority of the cases where it's empty, though. Looking at the ssl_npn_type probe, nearly 90% of connections do negotiate NPN, though, so I don't know what's going on there: https://glam.telemetry.mozilla.org/firefox/probe/ssl_npn_type/explore?activeBuckets=%5B%223%22%2C%220%22%2C%221%22%2C%222%22%2C%224%22%2C%225%22%2C%226%22%2C%227%22%2C%228%22%2C%229%22%5D&channel=beta&process=parent
Description
•