Bug 284559 – Safari 18.2 non-secure site connections warning blocks localhost with no option to proceed

• Status: NEW
• Component: Page Loading

[Jeff Johnson]

Created attachment 473554 [details]
Sample html to reproduce the bug

Steps to reproduce:
1) Open Safari 18.2
2) In Safari Security Settings, enable "Warn before connecting to a website over HTTP"
3) Download the attached index.html file
4) In Terminal, cd ~/Downloads; /usr/bin/python3 -m http.server
5) In Terminal, open -a Safari 'http://localhost:8000'

Expected results: "This Connection Is Not Secure" warning, with options to Continue or Go Back

Actual results: Safari can't open the page "http://localhost:8000/". The error is: "Navigation failed because the request was for an HTTP URL with HTTPS-Only enabled" (WebKitErrorDomain:305)

Notes: This is the new Safari 18.2 feature described at https://webkit.org/blog/16301/webkit-features-in-safari-18-2/#security-and-privacy

[Radar WebKit Bug Importer]

<rdar://problem/141532147>

[John Wilander]

Hi! Thanks for filing!

Can you manually enter 'http://localhost:8000' in the URL bar, including the scheme http://, and then load the page?

[Jeff Johnson]

(In reply to John Wilander from comment #3)
> Hi! Thanks for filing!
> 
> Can you manually enter 'http://localhost:8000' in the URL bar, including the
> scheme http://, and then load the page?

Yes.

[John Wilander]

OK, so then there's at least a workaround for now. Thanks!

[John Wilander]

Note that that is a deliberate thing. Explicitly stating a plaintext scheme should allow loading it.

To add to this. Somehow, on one of my machines (Safari 18.5), localhost got in a state where it won't load in Safari anymore:

    Safari can't open the page "http://localhost:3000/". 
    The error is: "Navigation failed because the request was for an HTTP URL with HTTPS-Only enabled" (WebKitErrorDomain:305)

This happened consistently when I typed "L" in the address bar and confirmed the autocomplete.
Now since I typed the full address, also with http:// it worked, and the problem disappeared for autocomplete, too.

However, as with the original bug report, when following a http://localhost:3000/ link, it still blocks.

Removing website data for localhost doesn't accomplish anything for this problem (this is a common suggestion on the web) and apparently there's no way (anymore) to remove the HSTS cache for Safari - if that's even relevant.

So far, this is probably exactly the same as the original post.

What I did notice is that when I close the tab presenting the error, and then Cmd+Z to reopen the tab, it always loads.

I would expect:
- this blocking to never happen for localhost
- that there is a documented way to break through the blockade (permanently)