Using // instead of prototcol [duplicate]

Question

Possible Duplicate:
Is there any downside for using a leading double slash to inherit the protocol in a URL? i.e. src=“//domain.com”

I have seen the following logic in many places, f.ex the analytics script:

script.src = ('https:' == document.location.protocol ? 'https' : 'http') +
    '://example.com/cdn.js';

But to my knowledge, you could just as well do:

script.src = '//example.com/cdn.js';

and it should use whatever protocol that is currently used. Or am I missing something? What is considered "best practice"?

I’m not looking for browser compatibility answers, google already recommends // for CDN scripts so that shouldn’t be the case here.

Here’s a fiddle, but it doesn’t really say much more than it seems to work in this setup: http://jsfiddle.net/6ZGyb/

Answer 1

A bit of background:

The additional JavaScript protocol wrapper is usually there to assure all browsers' support for such relative path URLs. You're right to assume most current browsers handle such URLs properly anyway, however for the sake of being able to sleep with a rested mind, it's still generally considered a good practice to assume not all user-agents accessing your web pages are as savvy as we'd expect them to be (or, supporting RFC 1808 Section 4, RFC 2396 Section 5.2, or RFC 3986 Section 5.2 as already mentioned in Is there any downside for using a leading double slash to inherit the protocol in a URL? thread as @Bruno pointed out in the comment)

Compatibility concerns:

Imagine a scenario where contents containing such relative paths are accessible 'out-of-context', e.g. in a email client. In this case such relative paths might be parsed to their fully qualified paths the wrong way and cause all kinds of problems, from users not being able to see contents properly, to accessing contents they really shouldn't be. To avoid any such issues, use of relative paths should always be limited to in-context cases where the parser of the parent document (opener application) can determine the complete absolute path to the resource in question. You should only expect relative paths to work properly when they'll be accessed by same or compatible protocol.

Security concerns:

Another possible concern that was raised is:

Could such relative protocol URLs be exploited in any way by accessing (parsed URL) parent document contents by various exchange protocols, and if such JavaScript wrapper serves a purpose of deflecting such access.

The (long) list of official IANA registered URL schemes suggests there's a lot of potentially worrying exchange protocols that could be used by exploiters, however JavaScript wouldn't do much anything on user-agents that don't have support for JavaScript (or is disabled by user). My answer would, with that in mind, have to be - no (for the 'JavaScript protecting access using other protocols' part).

As for the remaining part of the raised concern ('could such relative protocol URLs be exploited in any way'), the answer depends on how well this was considered when setting up the web server serving any such contents, does it even support/handle such requests (if it doesn't then it's a non-issue), and what possible vectors of attack/content theft were considered before deployment. In other words, it's a web server administration problem and certainly not something web designers/programmers could/should answer. Each end-user accessible protocol should have its own set of security protocols on top of it.