Is it valid to replace http:// with // in a <script src="http://...">?

Question

I have the following tag:

<script type="text/javascript" src="https://cdn.example.com/js_file.js"&gt;&lt;/script&gt;

In this case the site is HTTPS, but the site may also be just HTTP. (The JS file is on another domain.) I'm wondering if it's valid to do the following for convenience sake:

<script type="text/javascript" src="//cdn.example.com/js_file.js"></script>

I'm wondering if it's valid to remove the http: or https: ?

It seems to work everywhere I have tested, but are there any cases where it doesn't work?

Answer 1

This will work for both.

<script type="text/javascript">
document.write([
    "\<script src='",
    ("https:" == document.location.protocol) ? "https://" : "http://",
    "foo.js' type='text/javascript'>\<\/script>"].join(''));
</script>

Answer 2

A relative URL without a scheme (http: or https:) is valid, per RTF 3986: Section 4.2. If a client chokes on it, then it's the client's fault because they're not complying with the URI syntax specified in the RFC.

Your example is valid and should work. I've used that relative URL method myself on heavily trafficked sites and have had zero complaints. Also, we test our sites in Firefox, Safari, IE6, IE7 and Opera. These browsers all understand that URL format.

Answer 3

If its in another domain, check out the HTTP Referer header. This will contain the referring page. From there take the scheme

Referer: https://some.other.domain/blah.html

Extract on the server side and add in to the page. However, have to say, I like the document.location.protocol solution proposed.

Answer 4

It is perfectly valid to leave off the protocol. The URL spec has been very clear about this for years, and I've yet to find a browser that doesn't understand it. I don't know why this technique isn't better known, it's the perfect solution to the thorny problem of crossing HTTP/HTTPS boundaries. More here: Http-https transitions and relative URLs

Answer 5

Many people call this a Protocol Relative URL.

It causes a double-download of CSS files in IE 7 & 8.

Answer 6

Here I duplicate the answer in http://stackoverflow.com/questions/954327/hidden-features-of-html/960111#960111:

Using a protocol-independent absolute path:

<img src="//domain.com/img/logo.png"/>

If the browser is viewing an page in SSL through HTTPS, then it'll request that asset with the https protocol, otherwise it'll request it with HTTP.

This prevents that awful "This Page Contains Both Secure and Non-Secure Items" error message in IE, keeping all your asset requests within the same protocol.

Caveat: When used on a <link> or @import for a stylesheet, IE7 and IE8 download the file twice. All other uses, however, are just fine.

Answer 7

Yes, this is documented in RFC 3986, section 5.2:

(edit: Oops, my RFC reference was outdated).

Answer 8

It is guaranteed to work in any mainstream browser (I'm not taking browsers with less than 0.05% market share into consideration). Heck, it works in Internet Explorer 3.0.

RFC 3986 defines a URI as composed of the following parts:

     foo://example.com:8042/over/there?name=ferret#nose
     \_/   \______________/\_________/ \_________/ \__/
      |           |            |            |        |
   scheme     authority       path        query   fragment

When defining relative URIs (Section 5.2), you can omit any of those sections, always starting from the left. In pseudo-code, it looks like this:

 result = ""

  if defined(scheme) then
     append scheme to result;
     append ":" to result;
  endif;

  if defined(authority) then
     append "//" to result;
     append authority to result;
  endif;

  append path to result;

  if defined(query) then
     append "?" to result;
     append query to result;
  endif;

  if defined(fragment) then
     append "#" to result;
     append fragment to result;
  endif;

  return result;

The URI you are describing is a scheme-less relative URI.