In a URL, what is // for?

Typically, when I see //, it's usualy following some protocol prefix like http: or ftp:. I have never seen it placed anywhere else. For example,

http://www.google.com/

is a typical URL.

However, I found the following two syntaxes to yield different versions of the same site,

http://www.weather.com/

http://www.weather.com//

I would have thought that // anywhere other than the protocol specification would be invalid. To my surprise, I was wrong. What is it about the ending //that yeilds a different version of the same site?

EDIT:

Somebody at that site must have caught wind of the other because both links now land on the same page.

Chad Harrison

Posted 2012-08-23T20:05:06.563

Reputation: 5 759

9If I had to guess, all you're doing is seeing the same site twice but the one with the extra / on the end is breaking the CSS or whatever kids these days use to format their websites with. :) – Mark Allen – 2012-08-23T20:16:08.113

http://webmasters.stackexchange.com/ might be a better fit for this question. – Mehper C. Palavuzlar – 2012-08-23T20:23:17.417

1@MehperC.Palavuzlar In retrospect, yes. But at the time of the question, I thought the scope was somewhat wider than what it is. – Chad Harrison – 2012-08-23T20:25:47.913

@MarkAllen Well its interesting to note that using /// or //// at the end of the URL resulted the same site as / where // did result in something different. – Chad Harrison – 2012-08-24T14:01:24.983

Meanwhile the double backslash (\) is commonly seen in Windows's Uniform Naming Convention, e.g., \\HostName[@Port]\SharedFolder\Resource – William C – 2012-08-24T14:34:44.070

Answers

The leading // is part of the URL syntax. The inventor of the world wide web has apologized for that mistake.

Really, if you think about it, it doesn’t need the double-slash. I could have designed it not to have the double-slash. -- Sir Tim Berners-Lee, inventor of the world wide web

As for the trailing //, it's really not a double slash. The first slash separates the host name from the path. The last slash is the path. A web server can, if it wants to, treat a path of / different from an empty path, and apparently weather.com's does. As for whether this is by accident or intentional, you'd have to ask them about that.

David Schwartz

Posted 2012-08-23T20:05:06.563

Reputation: 58 310

That makes complete since, because you can configure a web server to look for an index other than just the web root! My hat's off to you good sir. – Chad Harrison – 2012-08-23T20:18:04.370

Are you saying http://example.com can be treated differently from http://example.com/ ? I didn't think that was the case with the first slash. – DisgruntledGoat – 2012-08-24T08:41:34.030

1@DisgruntledGoat You could, yes, using some .htaccess rules. But you probably shouldn't. – Matthew – 2012-08-24T09:53:15.013

@Matt that's strange though, because when you type the slash after the domain, the browser instantly removes it [edit: Chrome/Firefox remove it, IE actually adds it], implying that it's actually not possible for a browser to request each individually. Also the RFC link in another answer below says the slash is optional, implying they are identical. – DisgruntledGoat – 2012-08-24T10:38:14.053

1You can't treat http://example.com different from http://example.com/ in a web server, since they both have an empty path. You could treat them differently in a browser. – David Schwartz – 2012-08-24T11:12:56.940

neverminding the host header, zero or one slashes translates to the same http request: GET / HTTP/1.1: http://tools.ietf.org/html/rfc2616.html#section-3.2.3

– SingleNegationElimination – 2012-08-24T12:17:10.767

More recently, it could be argued that the double slash does have a role. Google recommend (to avoid accidentally calling insecure content from a secure page, for example) omitting the protocol from embedded resources (stylesheets, js etc), like this

<script src="//www.google.com/js/gweb/analytics/autotrack.js"></script>

So it is now apparent that such a protocol-less URL is a fully qualified URL and not a relative URL (which would begin with a single slash).

DaveP

Posted 2012-08-23T20:05:06.563

Reputation: 557

No more recommend. See also https://www.paulirish.com/2010/the-protocol-relative-url/

– lorond – 2016-10-19T13:44:59.290

1This style is called a "protocol relative" URL/URI. There's similar questions on SO. – hippietrail – 2012-08-24T17:33:35.257

To actually answer the question, the original specification gave the protocol http: (or possibly ftp:, gopher:, mailto:, news:, telnet:, wais:, file: or prospero:) then a // to indicate that the Uniform Resource Locator (URL) syntax was being used, then the host (optionally prefixed with user:password@) then address proper starting with another /. This was proposed in RFC 1738.

As the internet evolved, http: became the dominant protocol so browsers now assume that a prefix of http:// should be added if it isn't there.

StarNamer

Posted 2012-08-23T20:05:06.563

Reputation: 915

3Your answer would seem to indicate that something other than URL could have been used with the protocol at one point, and would have used something other than // to indicate it was in use... Is that so? – Izkata – 2012-08-24T03:15:28.820

3@Izkata In the late 80s and 90s, when the internet was starting up, there were several different formats suggested for various items. URLs were/are a subset of URNs (see RFC 3305) and these can have varying formats, e.g. isbn:1-23-456789-12-3. In practics, the http: defines that the rest will be a URL. RFCs are just proposals and often allow for extensions which never materialize. At one point, Tim Berners-Lee said that the // was for a 'subnet' (eg. http:/govnet/whitehouse.gov). This idea was never used, but '//' remains as so much code now expects and checks for it. – StarNamer – 2012-08-24T12:06:31.693

@Izkata: you would probably not see a non-URL URN used with a communications protocol; that's what the // is for. It indicates that the protocol is being used to access a (possibly remote) network location where a resource is to be found. There are plenty of other URN's that have other data parts and don't use // (your browser probably recognizes "mailto:", for example). See: http://en.wikipedia.org/wiki/URI_scheme

– KutuluMike – 2012-08-24T15:23:20.390

@MichaelEdenfield Well, that's what I'm wondering now. Was there ever a point where it was intended to be used differently - something different that could communicate through the same protocol. As a crude example, could the intention at one time have been for http://www.google.com/ and http:%/74.125.225.97/ to both be valid, and // indicate a hostname while something else like %/ indicate an IP address? – Izkata – 2012-08-24T15:46:47.743

1I don't think so. At least I've never seen any draft documents/examples/etc that have alternative heirarchy scheme for URLs. My impression has always been that TBL just wanted something to make it obvious that a URL pointed to an actual resource (and not arbitrary data), and using // made things look sufficiently-file-like. Every other style of URN I've ever seen has no special prefix in it's data part. Some protocols do allow that (I think telnet and gopher, e.g.) but I've never seen anything like that for http(s). – KutuluMike – 2012-08-24T15:53:37.580

I'd like to add to David's accepted answer:

Despite the apology of inventor of the web I think the double-slash syntax served an important purpose: to visually stand out. Double-slashes allowed easy visual distinction of URLs in a text without hyperlinks. When you saw double slashes you immediately thought it could be entered in a browser window, similar to how you thought a text containing @ could be used to send an email. It was especially crucial during the transition phase to web where protocols of that era (ftp, telnet, gopher) had their own weird notion to represent server addresses or resource paths, rarely both. Most of the problems associated with double-slashes would still exist, because double slashes are the least cryptical part of a URL, think about port numbers, percent encoding and case-sensitivity. But having a URL like http:something.com could easily be confused with my example here:something.com. Look at http:// on the other hand, how it shines like a diamond. Double-slashes have been an important part of Web symbolism and I believe it accelerated it's adoption rate too, even if it was unintentional.

They also might have made AmigaOS's job easier to differentiate between file names and URLs since AmigaOS used the file path syntax volume:path/to/destination. :)

Sedat Kapanoglu

Posted 2012-08-23T20:05:06.563

Reputation: 733