4

I noticed CDNs use // in the beginning of the source of the script.

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>  

This doesn't work locally (obviously), so I add http: before //

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>  

So... why do they put // in the beginning instead of http://? what is the significance? Is it some sort of DNS prefetch?

Also, is the // useless if the script element is at the bottom of the page?

https://developer.mozilla.org/en-US/docs/Web/HTTP/Controlling_DNS_prefetching

Matthew
  • 2,158
  • 7
  • 30
  • 52
  • 4
    `//` would detect the current used protocol by the client, so if you are using `https://`, it will call `https://ajax.googleapis.com...`, while if you are using `http://` on the website, it will call `http://ajax.googleapis.com....`. This surely has some problems, as if you were on a file protocol (`file://`) it will call `file://ajax.googleapis.com...`, which doesn't exist. – Picrofo Software Aug 16 '14 at 02:28
  • check this [link](http://stackoverflow.com/questions/6785442/browser-support-for-urls-beginning-with-double-slash) – Redaa Aug 16 '14 at 02:28
  • @PicrofoSoftware So, basically it's a forgiving way of saying, "I accept https OR http?" – Matthew Aug 16 '14 at 02:29
  • 1
    @Matthew Haha, exactly! In fact this doesn't always have to be https/http, it depends on the protocol being used by the client's web browser. This is actually to load scripts properly, because if you were using `https://` and the website requested to load unsecured content (from `http` protocol), the content will be blocked unless you allow it by your browser. However if you were to be using `http://` and requested to load content securely (`https://`) that would be fine; so it's more safer to load the content securely in both cases. – Picrofo Software Aug 16 '14 at 02:32
  • Think about it as being similar with relatives URLs. You can either specify the host (`www.example.com/path`) or you don't (`/path`). – Felix Kling Aug 16 '14 at 02:38
  • Note that while always loading content over HTTPS gives you less warning in both HTTP and HTTPS situations, HTTPS kills caching proxy. Since CDNs are often used in cases of highly distributed content and where performance highly matters, having to actually load directly from the CDN's server instead of a squid proxy set up by your local internet service provider may cause a difference in your total bandwidth usage and performance. Always using HTTPS is not always the best when loading from CDN, so evaluate your needs properly. – Lie Ryan Aug 16 '14 at 02:43
  • 1
    @LieRyan: I don't think it is desirable to load data from some "random" proxy when being on a HTTPS site. Think about man-in-the-middle attacks. – Felix Kling Aug 16 '14 at 03:07
  • @FelixKling: Browsers will display a warning if you are on HTTP but your CDN on HTTPS. There's no choice there. I was talking about when your site is HTTP, you need to consider carefully if you really need to always load from HTTPS CDN from a normal HTTP site. Also these proxies are provided by the network operator, if **your users** don't trust their own network provider then they should've moved to a different network provider, or if your content is of the nature that **you** can't trust other people's network provider, then you should build a HTTPS-only site. – Lie Ryan Aug 16 '14 at 03:14
  • @LieRyan: Oh I thought you meant the other way round. Sorry. – Felix Kling Aug 16 '14 at 03:15

1 Answers1

10

// is a relative protocol indicator. It will load over whatever protocol is currently being used. If you're loading the page over http:, it will load the resource over http:. If you're loading it over https:, it will be loaded over https:. This is important because pages loaded over HTTPS should also load their resources over HTTPS for security purposes.

The reason why it doesn't work locally is because locally, you're using the file: protocol (obviously), so it's going to try to load the resource over file:, which won't work because it's a URL, not a file path to a resource in your directory.

You might also want to take a look at this page describing its usage (tips, common pitfalls, etc.) and the tag.

AstroCB
  • 12,337
  • 20
  • 57
  • 73