35 ms·

"//" should indicate a URL

36 points by skybus 15y ago

nbpoole 15y ago
The // prefix is actually used for protocol-relative URLs. So //google.com leads to https://google.com https://google.com on a page with SSL, and it leads to http://google.com http://google.com on an unencrypted page. See: http://nedbatchelder.com/blog/200710.html#e20071017T215538 http://nedbatchelder.com/blog/200710.html#e20071017T215538 http://paulirish.com/2010/the-protocol-relative-url/ http://paulirish.com/2010/the-protocol-relative-url/
- astrodust 15y ago
  Doesn't seem like it would be that abusive for it to end up being "auto-detect" when there is nothing to be relative to. A "//" link in an HTTPS site would be required to be the same protocol anyway. It's only the spdy->http fallback that could prove to be a nuisance.
- rufibarbatus 15y ago
  Conversely, the protocol bit is relevant whenever your link is not domain- or protocol-relative, or when you can't be sure. And you can't be sure. Here's why: if someone saves your page on their hard drive and you're using protocol-relative URLs, the implied "http" just became "file". (Which in fact may be a nice excuse for some clever hacks.) Test it yourself! Save the following snippet to your computer and see how your browser resolves the URL: <!DOCTYPE html> <title>Testing 1 2 3</title> <p><a href="//google.com/">Linky</a></p>
  - sjs 15y ago
    You're assuming people care about that use case. I think in most cases it's irrelevant.
    - Vivtek 15y ago
      Oh man. Are you really saying that corner cases are a priori negligible? That seems like a dangerous road to start down when you're discussing basic protocols!
      - sjs 15y ago
        If your use case entails people saving your site to disk then you have may not be able to use // for protocol relative links, but most people don't have to worry about such things. I'm saying that those who need to worry about such things should and the rest of us should not. Nothing more and nothing less.
  - rawsyntax 15y ago
    wget has switches to replace http with file when saving a website to disk
  - teyc 15y ago
    HTML Base tag is your friend. http://www.w3schools.com/TAGS/tag_base.asp http://www.w3schools.com/TAGS/tag_base.asp
    - sleepyhead 15y ago
      W3Schools is not your friend. http://w3fools.com/ http://w3fools.com/
    - rufibarbatus 15y ago
      And here it is in the specification: http://dev.w3.org/html5/spec/Overview.html#the-base-element http://dev.w3.org/html5/spec/Overview.html#the-base-element And accordingly, adding `<base href="http://example.com/ http://example.com/ >` to that test above seems to work well on modern browsers.
- nyellin 15y ago
  Cool, I didn't know that. // has another meaning in XML XPath, a language for navigating XML documents. // selects nodes anywhere in a document. For example, //p would select all paragraphs in an XHTML page.
- jonursenbach 15y ago
  The problem with this is that browsers that are older than IE8 don't support it, so if you're still targeting those users you're SOL on this method.
  - jonhohle 15y ago
    I've used this technique since 2006 or so with IE6. The only concern I know of relates to using odd port numbers without a protocol in IE (but I don't think this is a concern if the protocol is relative). At the time, every other browser tested worked as well (not that that was much of a shock). I don't have a copy of IE6 to test on at the moment, but what makes you think IE8 is required for relative protocols?
    - ryanpetrich 15y ago
      IE6 will also fetch some resources twice if they are protocol-relative URLs
      - justincormack 15y ago
        That doesn't wound like a shopstopper... optimising performance for IE6 is kind of pointless..
drivebyacct2 15y ago
http://www.google.com http://www.google.com and https://www.google.com https://www.google.com have two entirely different meanings when you get right down to it. Plus `//` is already used as a protocol agnostic way of accessing resources in HTML.
- justinbaker 15y ago
  lol subdomains ^^
- masklinn 15y ago
  Not protocol agnostic, protocol relative.
jaysonelliot 15y ago
I assume that the author intends // to replace http:// http://, and that all other protocols such as ftp, https, etc. would still be written? If that's the case, why bother with the // at all? Why not just assume, as most browsers already do, that there's an inferred http:// http:// at the beginning of whatever the user types in the address bar? (EDIT - I see that he's talking about how we would refer to URLs in things like print advertisements. Cute idea, but given the ubiquity of web addresses in mass media, and the time it takes for the public to learn anything new, it still sounds like a solution in search of a problem. The average American is still not sure how Twitter works, or what it means when they see a @name or a #tag.)
- innes 15y ago
  Sorry for the meta-comment, but you seem to be the only person here who actually got what the article was saying.
sliverstorm 15y ago
I'm still not convinced anything is actually broken.
dedward 15y ago
Throw in gratuitous use of srv records and i'll go for it
jexe 15y ago
It's funny, Tim Berners-Lee feels pretty much the opposite way: http://bits.blogs.nytimes.com/2009/10/12/the-webs-inventor-regrets-one-small-thing/ http://bits.blogs.nytimes.com/2009/10/12/the-webs-inventor-r...
dbrock 15y ago
URL detection is tricky because people omit the “http://” http://” part of URLs. It used to be that you could look for stuff beginning with “www.”, but nobody uses “www.” anymore, so now you basically have to have a list of TLDs and look for anything ending in “.<tld>”. Now that everybody will be able to register their own TLD, will URL detection even be feasible for humans any more? I’ve been thinking about how we’re going to solve this problem for a while, because we need some kind of notation to replace “.<tld>”. I mean I don’t think people will go back to writing <http://coca-cola> http://coca-cola>, so when I saw the title of this post I immediately knew what the idea was: let’s write //coca-cola to denote “the URL coca-cola”. (Unfortunately, both Google Chrome and Safari interpret “//coca-cola” as “file:///coca-cola”.) I don’t know why everybody is talking about the technical meaning of //coca-cola, as that’s kind of irrelevant. Us web developers will of course still be typing the full http://coca-cola http://coca-cola, as we always have.
- justincormack 15y ago
  I thought this might be an issue when they did generic TLDs, but as far as I can see they are only selling to registrars, so they are not expecting web sites at the top level, there will still be a subdomain, and browsers will probably not go to the top level domains. Interestingly, http://dk/ http://dk/ has a valid A record to 193.163.102.24 which curl will show is a 301 redirect, but you cannot load it in Chrome or Firefox. dk has MX records too (I remember an old story about someone who had the email address m@dk or similar), but I think generally having any records for the top level is frowned upon now.
- Terretta 15y ago
  > nobody uses “www.” anymore Except for the vast majority of high volume sites that know how to balance traffic and don't show "fail whales" every couple days. Visit google.com, yahoo.com, amazon.com, msn.com, etc, and watch your URL get fixed to correctly reflect the local hostname "www". Even coca-cola.com. You can type it wrong as you always have, and they'll fix it for you to be "http://www.coca-cola.com/ http://www.coca-cola.com/.
mukyu 15y ago
Wouldn't load for me. mirror: http://webcache.googleusercontent.com/search?q=cache:skyb.us/content/search-prefix-should-indicate-url&hl=en&strip=1 http://webcache.googleusercontent.com/search?q=cache:skyb.us...

36 points by skybus 15y ago

The // prefix is actually used for protocol-relative URLs. So //google.com leads to https://google.com https://google.com on a page with SSL, and it leads to http://google.com http://google.com on an unencrypted page. See: http://nedbatchelder.com/blog/200710.html#e20071017T215538 http://nedbatchelder.com/blog/200710.html#e20071017T215538 http://paulirish.com/2010/the-protocol-relative-url/ http://paulirish.com/2010/the-protocol-relative-url/

astrodust 15y ago
Doesn't seem like it would be that abusive for it to end up being "auto-detect" when there is nothing to be relative to. A "//" link in an HTTPS site would be required to be the same protocol anyway. It's only the spdy->http fallback that could prove to be a nuisance.
rufibarbatus 15y ago
Conversely, the protocol bit is relevant whenever your link is not domain- or protocol-relative, or when you can't be sure. And you can't be sure. Here's why: if someone saves your page on their hard drive and you're using protocol-relative URLs, the implied "http" just became "file". (Which in fact may be a nice excuse for some clever hacks.) Test it yourself! Save the following snippet to your computer and see how your browser resolves the URL: <!DOCTYPE html> <title>Testing 1 2 3</title> <p><a href="//google.com/">Linky</a></p>
- sjs 15y ago
  You're assuming people care about that use case. I think in most cases it's irrelevant.
  - Vivtek 15y ago
    Oh man. Are you really saying that corner cases are a priori negligible? That seems like a dangerous road to start down when you're discussing basic protocols!
    - sjs 15y ago
      If your use case entails people saving your site to disk then you have may not be able to use // for protocol relative links, but most people don't have to worry about such things. I'm saying that those who need to worry about such things should and the rest of us should not. Nothing more and nothing less.
- rawsyntax 15y ago
  wget has switches to replace http with file when saving a website to disk
- teyc 15y ago
  HTML Base tag is your friend. http://www.w3schools.com/TAGS/tag_base.asp http://www.w3schools.com/TAGS/tag_base.asp
  - sleepyhead 15y ago
    W3Schools is not your friend. http://w3fools.com/ http://w3fools.com/
  - rufibarbatus 15y ago
    And here it is in the specification: http://dev.w3.org/html5/spec/Overview.html#the-base-element http://dev.w3.org/html5/spec/Overview.html#the-base-element And accordingly, adding `<base href="http://example.com/ http://example.com/ >` to that test above seems to work well on modern browsers.
nyellin 15y ago
Cool, I didn't know that. // has another meaning in XML XPath, a language for navigating XML documents. // selects nodes anywhere in a document. For example, //p would select all paragraphs in an XHTML page.
jonursenbach 15y ago
The problem with this is that browsers that are older than IE8 don't support it, so if you're still targeting those users you're SOL on this method.
- jonhohle 15y ago
  I've used this technique since 2006 or so with IE6. The only concern I know of relates to using odd port numbers without a protocol in IE (but I don't think this is a concern if the protocol is relative). At the time, every other browser tested worked as well (not that that was much of a shock). I don't have a copy of IE6 to test on at the moment, but what makes you think IE8 is required for relative protocols?
  - ryanpetrich 15y ago
    IE6 will also fetch some resources twice if they are protocol-relative URLs
    - justincormack 15y ago
      That doesn't wound like a shopstopper... optimising performance for IE6 is kind of pointless..

drivebyacct2 15y ago

http://www.google.com http://www.google.com and https://www.google.com https://www.google.com have two entirely different meanings when you get right down to it. Plus `//` is already used as a protocol agnostic way of accessing resources in HTML.

justinbaker 15y ago
lol subdomains ^^
masklinn 15y ago
Not protocol agnostic, protocol relative.

jaysonelliot 15y ago

I assume that the author intends // to replace http:// http://, and that all other protocols such as ftp, https, etc. would still be written? If that's the case, why bother with the // at all? Why not just assume, as most browsers already do, that there's an inferred http:// http:// at the beginning of whatever the user types in the address bar? (EDIT - I see that he's talking about how we would refer to URLs in things like print advertisements. Cute idea, but given the ubiquity of web addresses in mass media, and the time it takes for the public to learn anything new, it still sounds like a solution in search of a problem. The average American is still not sure how Twitter works, or what it means when they see a @name or a #tag.)

innes 15y ago
Sorry for the meta-comment, but you seem to be the only person here who actually got what the article was saying.

sliverstorm 15y ago

I'm still not convinced anything is actually broken.

dedward 15y ago

Throw in gratuitous use of srv records and i'll go for it

jexe 15y ago

It's funny, Tim Berners-Lee feels pretty much the opposite way: http://bits.blogs.nytimes.com/2009/10/12/the-webs-inventor-regrets-one-small-thing/ http://bits.blogs.nytimes.com/2009/10/12/the-webs-inventor-r...

dbrock 15y ago

URL detection is tricky because people omit the “http://” http://” part of URLs. It used to be that you could look for stuff beginning with “www.”, but nobody uses “www.” anymore, so now you basically have to have a list of TLDs and look for anything ending in “.<tld>”. Now that everybody will be able to register their own TLD, will URL detection even be feasible for humans any more? I’ve been thinking about how we’re going to solve this problem for a while, because we need some kind of notation to replace “.<tld>”. I mean I don’t think people will go back to writing <http://coca-cola> http://coca-cola>, so when I saw the title of this post I immediately knew what the idea was: let’s write //coca-cola to denote “the URL coca-cola”. (Unfortunately, both Google Chrome and Safari interpret “//coca-cola” as “file:///coca-cola”.) I don’t know why everybody is talking about the technical meaning of //coca-cola, as that’s kind of irrelevant. Us web developers will of course still be typing the full http://coca-cola http://coca-cola, as we always have.

justincormack 15y ago
I thought this might be an issue when they did generic TLDs, but as far as I can see they are only selling to registrars, so they are not expecting web sites at the top level, there will still be a subdomain, and browsers will probably not go to the top level domains. Interestingly, http://dk/ http://dk/ has a valid A record to 193.163.102.24 which curl will show is a 301 redirect, but you cannot load it in Chrome or Firefox. dk has MX records too (I remember an old story about someone who had the email address m@dk or similar), but I think generally having any records for the top level is frowned upon now.
Terretta 15y ago
> nobody uses “www.” anymore Except for the vast majority of high volume sites that know how to balance traffic and don't show "fail whales" every couple days. Visit google.com, yahoo.com, amazon.com, msn.com, etc, and watch your URL get fixed to correctly reflect the local hostname "www". Even coca-cola.com. You can type it wrong as you always have, and they'll fix it for you to be "http://www.coca-cola.com/ http://www.coca-cola.com/.

mukyu 15y ago

Wouldn't load for me. mirror: http://webcache.googleusercontent.com/search?q=cache:skyb.us/content/search-prefix-should-indicate-url&hl=en&strip=1 http://webcache.googleusercontent.com/search?q=cache:skyb.us...