"IP:Port" URL still interpreted as HTTP even with trimHttps, leading to inconsistency
Categories
(Firefox :: Address Bar, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr102 | --- | unaffected |
firefox-esr115 | --- | unaffected |
firefox117 | --- | unaffected |
firefox118 | --- | disabled |
firefox119 | --- | disabled |
firefox120 | --- | disabled |
firefox121 | --- | disabled |
firefox122 | --- | disabled |
People
(Reporter: heftig, Unassigned)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression, Whiteboard: [sng][search-papercut])
Say I'm connected to https://192.168.0.1:1234
.
With trimHttps
enabled, the address bar only displays 192.168.0.1:1234
but copying the entire location actually copies https://192.168.0.1:1234
. This is fine.
However, when I then edit the location to say 192.168.0.1:12345
and press enter, it interprets this as http://192.168.0.1:12345
instead of the https://192.168.0.1:12345
I expected.
https_first
and https_only
modes do not help. I suppose IP:Port addresses are excluded here.
Updated•9 months ago
|
Reporter | ||
Comment 1•9 months ago
|
||
Whoops, accidentally fat-fingered Return while editing the subject. Editing the rest...
Reporter | ||
Updated•9 months ago
|
Reporter | ||
Comment 2•9 months ago
|
||
Chrome restores the https://
when starting to edit, so it's not a problem there.
Comment 3•9 months ago
|
||
I filed a similar issue Bug 1847723. The problem is that Services.uriFixup.getFixupURIInfo
always prepends http://
if there is no protocol explicitly given.
Reporter | ||
Comment 4•9 months ago
|
||
https_only_mode
does help after enabling dom.security.https_only_mode.upgrade_local
, but https_first
is apparently never applied to addresses with a port.
Updated•9 months ago
|
Comment 5•9 months ago
|
||
What happens here is that by modifying the url it becomes something completely different, there's no given that 192.168.0.1:12345 uses the same protocol as 192.168.0.1:1234. Any assumption about a protocol here has a 50% chance of being wrong.
That's why I don't think this is a P2, we are doing our best with the information at hand, we can't know what the url is, we take the most likely (very few local servers are using https today, yet).
The work being done in bug 1812192 should help here, what we can do is to detect that the address bar added a protocol, and then allow a downgrade to http (or upgrade to https).
I'm tempted to just call this a dupe of bug 1812192, but let's keep it as a dep for now.
Comment 6•9 months ago
|
||
This bug has been marked as a regression. Setting status flag for Nightly to affected
.
Updated•9 months ago
|
Updated•9 months ago
|
Reporter | ||
Comment 7•8 months ago
|
||
Now that trimHttps
has been enabled by default, this is now affecting Nightly by default.
Comment 9•7 months ago
|
||
Set release status flags based on info from the regressing bug 1853418
Comment 10•7 months ago
|
||
I think editing the url makes it a wontfix, though a better solution for the users will be Bug 1848715, where on focus we will untrim the url, then when editing or copying the protocol will be there. So duping there.
Updated•6 months ago
|
Description
•