Safari inserts "localhost" in URLs with three slashes after the scheme

Question

Safari seems to be the only browser that differently handles URL's that have three slashes after the scheme.

For example typing https:///google.com in the address bar results in the URL being converted to https://google.com by all browsers I tried (Edge, Firefox, Opera, Tor), excepting for Safari, which converts the URL to https://localhost/google.com.

The conversion also happens when receiving a HTTP redirect (301 or 302) with a "malformed" URL, but doesn't happen when clicking on a link, in that case Safari is consistent with the other browsers.

Does somebody know why is that? And who's correct - Safari inserting localhost, or the other browsers stripping out the third slash?

Answer 1

What happens when the text is entered in the address bar of the browser is not tied by any specs yet, so for this situation there is no "wrong" or "correct" behavior.

However, for redirects sent by the server in response to a fetch request, the Fetch standards rule, and these standards(§8.2 - "follow") ask that the `Location` header in the response be parsed through the URL standards URL-parser algorithm.

This algorithm when it will encounter the third / in the special authority ignore slashes state will emit a validation error, but won't leave this step until all subsequent / are found (and thus ignored).

So the result of parsing an input such as https:///////example.com should be

protocol: "https:"
host: "example.com"
path: "/"

I.E, the multiple / characters after https: are ignored.

And even Safari agrees on that in other places, like in HTML's <a href>, as can be seen from the links in OP.

That they don't follow this rule for fetch redirects is a bug, and as such, you may want to report it to their bug-tracker.

Answer 2

@AlvarPaalberg's answer gives an earlier view

There are later RFCs that I think add to this.

The one I found is RFC7230 defining the http protocol. This includes

A sender MUST NOT generate an "http" URI with an empty host identifier. A recipient that processes such a URI reference MUST reject it as invalid.

Also RFC3986

If the URI scheme defines a default for host, then that default applies when the host subcomponent is undefined or when the registered name is empty (zero length). For example, the "file" URI scheme is defined so that no authority, an empty host, and "localhost" all mean the end-user's machine, whereas the "http" scheme considers a missing authority or empty host invalid.

From that I think all the browsers are incorrect. They should be rejecting the URL as invalid. Now browsers in general have never liked reporting errors for invalid html or anything else so they decide what they think the user typed and use that instead.

Safari has chosen a different view to others. (It has used the rule for the file: scheme - which I guess is due to Safari developers being more integrated withe the OS developers than is the case for other browsers. macOS system APIs us file URLs for most file operations)

Answer 3

One can try to give answer to the question why? but not who is correct?

---

RFC 1738 - Uniform Resource Locators (URL):

The file URL scheme is used to designate files accessible on a particular host computer. This scheme, unlike most other URL schemes, does not designate a resource that is universally accessible over the Internet.

A file URL takes the form:

    file://<host>/<path>

/../ As a special case, can be the string "localhost" or the empty string; this is interpreted as `the machine from which the URL is being interpreted'.

---

So it appears that Safari considers three slashes as file URL scheme special case (empty string) and replaces empty string between second and third slash with 'localhost'. Other browsers consider it as user entered one slash too much and actually want to access internet resource so they 'autocorrect' it.