1757503 - 2 second delay before processing HTTP request

Status: RESOLVED INVALID

(Core :: DOM: Security, defect)

Description

[Frank Forte]

Attachment: slow_page_load.png

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

Steps to reproduce:

I visited a web page with TLD ".test" that points to 127.0.0.1.

Actual results:

There was a 2 second delay, then the request was sent and the page was loaded. Developer tools says that the request was blocked for 1ms, then waiting for 2ms, and everything else was 0ms (see the attached file).

I created a web page that output "test" and exits to make sure it was not the application causing the issue.

The same request using other browsers loads instantly.

This issue is intermittent, and happens more often with private browsing mode. I tried re-installing Firefox (it was version 97.0.1 (64-bit) before and after the re-install) but the problem still happens.

Expected results:

The page should load in under 100ms.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 2

[Kershaw Chang [:kershaw]]

Hi Frank,

Could you try to get a http log?

Thanks.

Comment 3

[Frank Forte]

Attachment: FFlog2.txt-main.13260.moz_log

For this request, I had the private browsing window open. I clicked the address bar and pressed "enter". There was a 2 second delay before the request started and the page displayed. This was logged in the file FFlog2.txt-main.13260.moz_log

The developer tools console showed two requests. One empty that took 2329ms, then the successful one that took 2ms.

I did a second request as FFlog3.txt-main.13260.moz_log where I clicked "refresh" and the page loaded instantly.

Comment 4

[Frank Forte]

Attachment: FFlog3.txt-main.13260.moz_log

In this request logged in FFlog3.txt-main.13260.moz_log, I just clicked "refresh" and the page loaded quickly.

Comment 5

[Frank Forte]

Attachment: firefox_screenshot_slow_and_fast_requests.png

In this screenshot of the network tab of the developer tools console, you can see the failed request that is about 2 seconds, right before a successful request. That happens when clicking the address bar and hitting "enter".

When clicking the "refresh" button, this issue does not happen (the third request in the screenshot, which is fast).

Comment 6

[Kershaw Chang [:kershaw]]

Thanks for the log.
This looks like related to https-only or https-first mode. Could you try to go to about:config and turn off the preference below?

dom.security.https_only_mode
dom.security.https_only_mode_pbm
dom.security.https_first 
dom.security.https_first_pbm

Comment 7

[Frank Forte]

The first three were already false. The last one dom.security.https_first_pbm was true. Changing that value to false prevents the bad request and the delay. However this does not fix the bug in the code:

When https_first_pbm is set to the default value (true), the request header has the following:
GET / undefined

when it should be
GET / HTTP/1.1

I do not like having to turn the httpd_first_pbm setting on and off, or leaving it off which would reduce security (I notice with the setting off we do not have the Sec-Fetch headers sent).

This is a bug, please see that private browsing mode sends the proper GET header on the first request (not "undefined")

Comment 8

[Frank Forte]

Attachment: firefox_screenshot_undefined_request.png

Comment 9

[Kershaw Chang [:kershaw]]

(In reply to Frank Forte from comment #7)

The first three were already false. The last one dom.security.https_first_pbm was true. Changing that value to false prevents the bad request and the delay. However this does not fix the bug in the code:

When https_first_pbm is set to the default value (true), the request header has the following:
GET / undefined

I think this is a bug in devtools, so I filed bug 1757891 for this.

Since this bug is related to https first mode, I'd change the component to DOM:Security and let them investigate more.

Comment 10

[Christoph Kerschbaumer [:ckerschb]]

Summing it up, this works as designed. Ff https-only-mode, or in this case https-first-mode is enabled. Then Firefox tries to upgrade the top-level request from http to https. If Firefox does not receive a response within a certain amount of time (2 seconds), then we send an anonymous background request. If that request answers faster then the upgraded top-level request, then we take that as a strong indicator that the top-level request will result in a time-out and we downgrade the top-level load to http.

There are more technical details in this blogpost and the linked paper:
https://blog.mozilla.org/attack-and-defense/2021/03/10/insights-into-https-only-mode/

The Devtools Bug seems valid however.