"It seemed like a good idea at the time": Berners-Lee 'sorry' for slashes | Hacker News Reader

"It seemed like a good idea at the time": Berners-Lee 'sorry' for slashes

news.bbc.co.uk

24 pointsshaddi19 comments

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.

It really doesn't. For example, try the URL http://paulgraham.com://articles.html

Yeah it does. try this:

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.

I guess one could have chosen another separator than ":" as port number prefix so there would be no ambiguity with the protocol suffix :)

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.

site:port/file could be considered illegal. A well-formed URL would be: protocol:site(:port)?(/path)?

where (...)? denotes optional parts.

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.

It's a smug joke!

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'

But them slashdot would have been colondot. Somehow it doesn't work as well.

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 "./")

http://news.slashdot.org/article.pl?sid=07/10/02/1553218

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:

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

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.

Weird.

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?

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.

I saw this story/fluff and didn't even think it was worthy of bbc, but they have been grasping at straws lately!

It amounts to: "OMG! Tim speekz!"

And what about having superfluous www-prefix in hostnames?

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.

Reply on news.ycombinator.com