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 spe

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