HN Explorer

27 comments

[ 2.8 ms ] story [ 66.3 ms ] thread
nbpoole
The // prefix is actually used for protocol-relative URLs. So //google.com leads to https://google.com on a page with SSL, and it leads to http://google.com on an unencrypted page.

See:

http://nedbatchelder.com/blog/200710.html#e20071017T215538

http://paulirish.com/2010/the-protocol-relative-url/

astrodust
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
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
You're assuming people care about that use case. I think in most cases it's irrelevant.
Vivtek
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
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
wget has switches to replace http with file when saving a website to disk
nyellin
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
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
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
IE6 will also fetch some resources twice if they are protocol-relative URLs
justincormack
That doesn't wound like a shopstopper... optimising performance for IE6 is kind of pointless..
jaysonelliot
I assume that the author intends // to replace 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:// 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
Sorry for the meta-comment, but you seem to be the only person here who actually got what the article was saying.
sliverstorm
I'm still not convinced anything is actually broken.
dedward
Throw in gratuitous use of srv records and i'll go for it
dbrock
URL detection is tricky because people omit the “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>, 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, as we always have.

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