Open Bug 1937852 Opened 2 months ago Updated 1 month ago

Don't HTTPS-First upgrade URLs with an explicit http:// scheme that were specified on the command-line

Categories

(Core :: DOM: Security, enhancement)

Product:
Core
Component:
DOM: Security
Type:
enhancement

Tracking

()

Status:
ASSIGNED

People

(Reporter: dholbert, Assigned: maltejur)

References

(Blocks 1 open bug)

Details

(Whiteboard: [domsecurity-active])

STR:

  1. Launch Firefox using a http URL -- for example:
mkdir /tmp/test-profile; firefox -profile /tmp/test-profile http://example.org

...or:

mozregression --launch 2022-12-14 -a http://example.org

ACTUAL RESULTS:
Firefox loads the https (secure) version of the URL.

EXPECTED RESULTS:
Firefox should load the http (insecure) version of the URL, since that's what I typed.

Note: that we give expected-results if I manually enter the URL in the address bar (as of bug 1919544 at least). It's just that the command-line input seems to be special for some reason.

Note: Not-too-surprisingly, this seems to be related to the dom.security.https_first pref -- if I turn off that pref, then I get EXPECTED RESULTS.

This sounds like a good improvement to me. I wouldn't call it a defect, as I think our current behavior is not exactly a bug. It is more a question of how much we want to HTTPS-First upgrade. But with the same reasoning as in Bug 1919544, I think it makes sense to change that behavior to be more in-line with what we do in the address bar.

I will look into implementing this. With the existing code from Bug 1919544, I think it shouldn't be too much work.

Assignee: nobody → maltejur
Status: NEW → ASSIGNED
Type: defect → enhancement
Summary: HTTPS-First upgrades URLs with an explicit http:// scheme that were specified on the command-line → Don't HTTPS-First upgrade URLs with an explicit http:// scheme that were specified on the command-line
Whiteboard: [domsecurity-active]
You need to log in before you can comment on or make changes to this bug.