Closed Bug 1731971 Opened 3 months ago Closed 2 months ago

https-first causes slow http: sites on non-standard ports to time-out too fast


(Core :: DOM: Security, defect, P3)

Firefox 91



95 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox-esr91 --- affected
firefox93 --- wontfix
firefox94 --- wontfix
firefox95 --- fixed


(Reporter: s.pasquier, Assigned: lyavor)


(Blocks 1 open bug, Regression, )


(Keywords: regression, Whiteboard: [domsecurity-backlog1])


(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

In navigation in private.
time out for a get request on a non standard port (different of port 80) is fixed at 3.5 s.
None parameter detected for this.

Actual results:

invalid time out

Expected results:

the time out use in navigation in private should be the same than in standard mode

The Bugbug bot thinks this bug should belong to the 'Firefox::Private Browsing' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Private Browsing

Could you please provide more detailed steps to reproduce this issue? Please also let us know if this is reproducible with addons disabled as well.

Flags: needinfo?(s.pasquier)

We can confirm that it's produce with addons disabled.
To reproduce the issue try this url :

In Navigation in private the response is Timeout
In "Normal" mode the response is ok
The script at this url wait 5 sec before to responde

Flags: needinfo?(s.pasquier)

By the way.
The timeout will occur even in normal mode, if set = true.
On the other hand. It can be accessed successfully in private browsing mode, if = false.

So, I think the problem is HTTPS-First Mode.

Component: Private Browsing → DOM: Security
Product: Firefox → Core

Trying to upgrade non-standard ports is a bit odd to start with. It's probably not going to work (a port can't be both TLS and not TLS), but for https_only we might as well try because we're not going to load the http: resource. The only time an upgrade might work is if the original http:// URL was a typo, but maybe we'll get lucky. Given the Address bar still defaults to adding http:// it's not unreasonable to try upgrading non-standard ports for navigations.

The TLS handshake failure actually comes back quickly here (SSL_ERROR_RX_RECORD_TOO_LONG). Why are we using a short timeout check when we fall back to the original URL? I looked around for time prefs associated with https-only/https-first and only found which is set to 3000 (3 seconds). I thought that was only used by https-only mode on how long to wait to fire off a potentially-racing http: request, but for kicks I increased it to 6000 and then this URL worked.

According to the Browser Console (not the web tools console) we fire a request to (note: http -- the https attempt doesn't show up). After the timer we fire off another request to the root of the site, and when that answers faster than the /site page we show the timeout error.

It looks like we fell back to using http:// quickly because of the TLS error, but maybe had already started the timer on the racing request. In this kind of case we either need to cancel the timer if we can, or when the timer fires have that code make sure we haven't already given up on TLS connection before it tries the racing connection.

Does that sound about right, Tomer?

Putting this in the backlog for now since you've already got a bunch of higher-priority https-first bugs assigned

Flags: needinfo?(lyavor)
Priority: -- → P3
Regressed by: 1716991
Whiteboard: [domsecurity-backlog1]
Summary: In navigation in private : time out issue on non standard port → https-first causes slow http: sites on non-standard ports to time-out too fast

Thank you for reporting!

That is a very interesting bug.
It's very odd because neither https-only nor https-first should upgrade non-standard ports:,361-371.

@Dan It sounds right!
Yes, https-first uses timeouts probably to provide better performance.

I will investigate it further!

Flags: needinfo?(lyavor)
Assignee: nobody → lyavor

The severity field is not set for this bug.
:ckerschb, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(ckerschb)
Severity: -- → S3
Flags: needinfo?(ckerschb)
Pushed by
https-first causes slow http: sites on non-standard ports to time-out too fast. r=ckerschb
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 95 Branch
You need to log in before you can comment on or make changes to this bug.