Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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.

share|improve this question

closed as off topic by Nifle, Mehper C. Palavuzlar, Xavierjazz, allquixotic, 8088 Aug 25 '12 at 7:26

Questions on Super User are expected to relate to computer software or computer hardware within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

9  
If 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 Aug 23 '12 at 20:16
    
webmasters.stackexchange.com might be a better fit for this question. –  Mehper C. Palavuzlar Aug 23 '12 at 20:23
1  
@MehperC.Palavuzlar In retrospect, yes. But at the time of the question, I thought the scope was somewhat wider than what it is. –  hydroparadise Aug 23 '12 at 20:25
    
@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. –  hydroparadise Aug 24 '12 at 14:01
    
Meanwhile the double backslash (\\) is commonly seen in Windows's Uniform Naming Convention, e.g., \\HostName[@Port]\SharedFolder\Resource –  William C Aug 24 '12 at 14:34

4 Answers 4

up vote 52 down vote accepted

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.

share|improve this answer
    
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. –  hydroparadise Aug 23 '12 at 20:18
    
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 Aug 24 '12 at 8:41
1  
@DisgruntledGoat You could, yes, using some .htaccess rules. But you probably shouldn't. –  Matt Potts Aug 24 '12 at 9:53
1  
You 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 Aug 24 '12 at 11:12
3  
neverminding the host header, zero or one slashes translates to the same http request: GET / HTTP/1.1: tools.ietf.org/html/rfc2616.html#section-3.2.3 –  TokenMacGuy Aug 24 '12 at 12:17

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.

share|improve this answer
3  
Your 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 Aug 24 '12 at 3:15
2  
@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 Aug 24 '12 at 12:06
1  
@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: en.wikipedia.org/wiki/URI_scheme –  Michael Edenfield Aug 24 '12 at 15:23
    
@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 Aug 24 '12 at 15:46
1  
I 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). –  Michael Edenfield Aug 24 '12 at 15:53

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. :)

share|improve this answer

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

share|improve this answer
1  
This style is called a "protocol relative" URL/URI. There's similar questions on SO. –  hippietrail Aug 24 '12 at 17:33
    
+1 Thanks, I didn't know that and never would have tried it. –  Alberto Aug 24 '12 at 20:55

Not the answer you're looking for? Browse other questions tagged or ask your own question.