You need the slashes. Otherwise how do you differentiate between:
site:port/file (example.com:8080/myfile.htm)
and
protocol:site/file (http:example.com/myfile.htm)
?
You could guess, based on where the full stops are, what's a numeric, etc. But you wouldn't be sure. Having dots for one separator, slashes for another and a double slash for the third makes it entirely clear where the breaks are.
The separators aren't to be matched globally, their order in the URL matters. The first // separates protocol from host. The second // isn't really - it's one slash to separate path from host, and the second slash is part of the path.
I thought he was referring to the http:// or ftp://. Without them it could be http:news.ycombinator.com or ftp:someserver.org.
Edit: Ok I reread your comment and understand it better. That could be a problem but there could be other solutions, but at the moment, I don't care to think them through.
Check if the part between the : and (end or /) is an integer? Sure, some browsers allow you to specify an IP address as an integer, but I don't think that's extremely useful.
Ive seen some heinous regexen floating around to recognize urls/uris. Be nice if this hadn't have happened - but he gave us the web, right, we can hardly complain.
I was completely oblivious to the // being a problem at all. Since it isn't necessary for >99% of non-geeky url usage, it only comes up once, when I explain that browsers are pretty smart and that part is optional with a couple of exceptions... and that is it.
Slashdot doesn't get its name from the web, it's just that Taco wanted something "unpronounceable", so he came up with "/." (perhaps influenced by the unix "./")
I always assumed that the www subdomain was the phase's solution for the problem of limited resources, and to reinforce that something used the Web, rather than gopher &c.
The is a few reasons that I know of, all of which are historical.
The first is that "www" or "web" were physical hosts in the company's network. These hosts ran the public webserver, but you might also see Spock, Nemoy and Sarek as developer workstations. Every machine had a subdomain, and www happened to be the one that ran the web software.
Note that web.archive.org, for instance, still resolves, as does web.altavista.com
The second reason is/was politeness. It was viewed as an improper use of resources to sent traffic directly to domain.com..
The reason for this is that all domain.com requests need to go up to the top-level DNS servers, where-as subdomain.domain.com will request using your local servers (ns1.domain.com, ns2.domain.com).
Thinking about it today, I'm not sure how much savings there'd really be.. You'd still need to ask the root servers what the IPs were for the domain's DNS servers, but it was viewed by my friends at the time as the politer option.
Finally, and I think this was the biggest one.. Today, we think of the web AS the internet.. That was very much not the case 15 years ago. The web was among the many services that ran on the internet, and people planned accordingly.
domain.com is the root for ALL of that's company's internet efforts. It shouldn't resolve to the web site, any more than it should resolve to the Nameserver, Mail servers, or Usenet servers. They're all co-equal services.
What someone really needs to apologise for is making the order of "least to most specific term" go from right-to-left in a domain name and left-to-right in the path component of a URL.
It's an implementation detail. It's not the "//" that matters, it's that web browsers weren't offering reasonable abstractions; so this weird detail affected more people than it should have.
These days, you can type "foobar" instead of http://www.foobar.com/ in any browser, and it works. The "//" isn't a big deal.
There's more that browsers could be doing. Why ever display "<anything>://" in a browser, when it could be a menu of protocols?
Actually, the double slash is useful for at least one thing. You can use it in web pages to make relative URLs which preserve the protocol, but change the server.
Suppose you have pages on a server www.example.com that reference images on an asset host assets.example.com. Usually, you would use a full URL in your HTML to reference your images:
This is fine if all your accesses to www.example.com are done over HTTP. But what if you want to use HTTPS sometimes? Unless you change those URLs to use the HTTPS protocol as well, the browser may give the 'mixed secure and insecure content' warning.
If you specify the image URLs as relative URLs in the form:
Without the double slash, this kind of relative URL would be indistinguishable from the more common relative URL which just means a different path on the same server:
21 comments
[ 3.2 ms ] story [ 68.7 ms ] threadIt amounts to: "OMG! Tim speekz!"
paulgraham.com://articles.html
The separators aren't to be matched globally, their order in the URL matters. The first // separates protocol from host. The second // isn't really - it's one slash to separate path from host, and the second slash is part of the path.
Edit: Ok I reread your comment and understand it better. That could be a problem but there could be other solutions, but at the moment, I don't care to think them through.
where (...)? denotes optional parts.
Weird.
It's like Ritchie being asked what was the main fault in the C language - he said the 'CREAT' flag to open() should have been 'CREATE'
http://news.slashdot.org/article.pl?sid=07/10/02/1553218
The first is that "www" or "web" were physical hosts in the company's network. These hosts ran the public webserver, but you might also see Spock, Nemoy and Sarek as developer workstations. Every machine had a subdomain, and www happened to be the one that ran the web software. Note that web.archive.org, for instance, still resolves, as does web.altavista.com
The second reason is/was politeness. It was viewed as an improper use of resources to sent traffic directly to domain.com.. The reason for this is that all domain.com requests need to go up to the top-level DNS servers, where-as subdomain.domain.com will request using your local servers (ns1.domain.com, ns2.domain.com). Thinking about it today, I'm not sure how much savings there'd really be.. You'd still need to ask the root servers what the IPs were for the domain's DNS servers, but it was viewed by my friends at the time as the politer option.
Finally, and I think this was the biggest one.. Today, we think of the web AS the internet.. That was very much not the case 15 years ago. The web was among the many services that ran on the internet, and people planned accordingly.
domain.com is the root for ALL of that's company's internet efforts. It shouldn't resolve to the web site, any more than it should resolve to the Nameserver, Mail servers, or Usenet servers. They're all co-equal services.
These days, you can type "foobar" instead of http://www.foobar.com/ in any browser, and it works. The "//" isn't a big deal.
There's more that browsers could be doing. Why ever display "<anything>://" in a browser, when it could be a menu of protocols?
Suppose you have pages on a server www.example.com that reference images on an asset host assets.example.com. Usually, you would use a full URL in your HTML to reference your images:
http://assets.example.com/image.png
This is fine if all your accesses to www.example.com are done over HTTP. But what if you want to use HTTPS sometimes? Unless you change those URLs to use the HTTPS protocol as well, the browser may give the 'mixed secure and insecure content' warning.
If you specify the image URLs as relative URLs in the form:
//assets.example.com/image.png
then when a user visits http://www.example.com/ their browser will fetch the image from http://assets.example.com/image.png . But when they visit https://www.example.com/ their browser will fetch the image from https://assets.example.com/image.png .
Without the double slash, this kind of relative URL would be indistinguishable from the more common relative URL which just means a different path on the same server:
/assets.example.com/image.png