[tremon]

Your first example is a valid uri but not a valid http url, because it's missing a host part. Your second example is not a valid uri, as the spec requires that [scheme]:// is followed by a host indicator.

Neither has much to do with / normalization, which applies to the path part of a valid uri.

[yencabulator]

I believe host can be empty.

      host        = IP-literal / IPv4address / reg-name
      reg-name    = *( unreserved / pct-encoded / sub-delims )

https://www.rfc-editor.org/rfc/rfc3986#section-3.2.2

Of course, most software freely ignores RFCs when the end result "seems better".

[tremon]

Yes, the uri spec must allow the host part to be empty. That's easily shown by remembering that file:/// URIs are commonly preceded by three slashes, so the spec must allow for that. Not sure where the brain was going with that.

Still, it's not a valid http url. I looked up the current rfc for completeness sake: https://www.rfc-editor.org/rfc/rfc9110#section-4.2.1

> 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.

And it really is an empty host component, as RFC3986 section 3.2 specifically says:

> The authority component is preceded by a double slash ("//") and is terminated by the next slash ("/"), question mark ("?"), or number sign ("#") character, or by the end of the URI.

So yes, collapsing all those ////// into two really is illegal according to the spec -- but then again, the specs are mostly about network communication, so machine-to-machine. I consider a browser's url bar parsing to be more in the UX domain than in the technical domain.