

"It seemed like a good idea at the time": Berners-Lee 'sorry' for slashes - shaddi
http://news.bbc.co.uk/2/hi/technology/8306631.stm

======
AndrewDucker
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.

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

~~~
mseebach
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.

------
furriner
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'

------
chrismear
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

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

~~~
mahmud
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>

------
sophacles
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.

------
makecheck
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?

------
tome
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.

------
theblackbox
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!"

------
zokier
And what about having superfluous www-prefix in hostnames?

~~~
stilist
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.

~~~
e1ven
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.

