4 ms·

The // part isn't required for every scheme as the article implies. For example, tel:5555555555 is perfectly acceptable. The two slashes are even now consider

The // part isn't required for every scheme as the article implies. For example, tel:5555555555 is perfectly acceptable. The two slashes are even now considered a bad design decision originally: http://news.bbc.co.uk/2/hi/8306631.stm http://news.bbc.co.uk/2/hi/8306631.stm

timf 16y ago
More familiar example: mailto:
thwarted 16y ago
Yeah, the // isn't part of the scheme, it's part of the authority. That BBC article doesn't say why "net users" find them annoying. I like the double slashes (or at least some unique separator of the scheme from the hostname and designates where the hostname starts), since it allows building of useful relative URLs, as mentioned in the OA. As an example, not covered in the examples in the article, you don't need to serve different CSS files for secure and insecure content when you serve media assets from another domain which is also available via both http and https. The CSS background-image: url(//media.example.com/image.png) can be used on both HTTP and HTTPS served pages and the browser will resolve that relative URL by filling in the protocol from the base document. Without the double slashes, you wouldn't be able to distinguish between a relative path and a relative URL. If I remember correctly, a scheme change on the same hostname but with a different path like: base document: http://example.com/some/path relative URL: https:/some/other/path is possible too (I wonder how the parsing should work with port numbers, if they can be relative too -- I have not read the RFC in a while, and it's such a rare thing to use port numbers anyway). Double slashes (well, backslashes) is how Microsoft/CIFS originally designated server names in UNC paths, which I think may have been around before URLs were standardized (don't quote me on that, they're most likely roughly the same age and influenced each other). This is also why the file: scheme "requires" three leading slashes, as the "host" is empty to designate the local machine -- but you could put in a hostname to access network shares (I put "requires" in quotes because file has always had some ambiguities in the parsing implementations). I find it annoying when people read addresses and call them "backslashes". Talk about wasting time and energy, that's a whole additional syllable said for every path component in a URL!
- pak 16y ago
  These tricks by combining parts of URLs to do relative linking on scheme, host, etc. are little known but useful; I was expecting them to show up in the article. Going back to the debate over Chrome's potential dropping of "http:// http:// in the address bar, if they were to use "//" instead they would have an argument for technical correctness because the default protocol of "http:" could be assumed. But having no leading "//" visually confuses it with a relative path omitting the host, because it breaks the signifier for the authority component of the URL. Just a thought.
Hoff 16y ago
It can be an easy way to filter XSS attacks, however. Anything with :// or /.. in the parameter probably isn't, um, friendly.

timf 16y ago

More familiar example: mailto:

thwarted 16y ago

Yeah, the // isn't part of the scheme, it's part of the authority. That BBC article doesn't say why "net users" find them annoying. I like the double slashes (or at least some unique separator of the scheme from the hostname and designates where the hostname starts), since it allows building of useful relative URLs, as mentioned in the OA. As an example, not covered in the examples in the article, you don't need to serve different CSS files for secure and insecure content when you serve media assets from another domain which is also available via both http and https. The CSS background-image: url(//media.example.com/image.png) can be used on both HTTP and HTTPS served pages and the browser will resolve that relative URL by filling in the protocol from the base document. Without the double slashes, you wouldn't be able to distinguish between a relative path and a relative URL. If I remember correctly, a scheme change on the same hostname but with a different path like: base document: http://example.com/some/path relative URL: https:/some/other/path is possible too (I wonder how the parsing should work with port numbers, if they can be relative too -- I have not read the RFC in a while, and it's such a rare thing to use port numbers anyway). Double slashes (well, backslashes) is how Microsoft/CIFS originally designated server names in UNC paths, which I think may have been around before URLs were standardized (don't quote me on that, they're most likely roughly the same age and influenced each other). This is also why the file: scheme "requires" three leading slashes, as the "host" is empty to designate the local machine -- but you could put in a hostname to access network shares (I put "requires" in quotes because file has always had some ambiguities in the parsing implementations). I find it annoying when people read addresses and call them "backslashes". Talk about wasting time and energy, that's a whole additional syllable said for every path component in a URL!

pak 16y ago
These tricks by combining parts of URLs to do relative linking on scheme, host, etc. are little known but useful; I was expecting them to show up in the article. Going back to the debate over Chrome's potential dropping of "http:// http:// in the address bar, if they were to use "//" instead they would have an argument for technical correctness because the default protocol of "http:" could be assumed. But having no leading "//" visually confuses it with a relative path omitting the host, because it breaks the signifier for the authority component of the URL. Just a thought.

Hoff 16y ago

It can be an easy way to filter XSS attacks, however. Anything with :// or /.. in the parameter probably isn't, um, friendly.