Reputation: 1503
It's been an oft-discussed question on StackOverflow what this means:
<script src="//cdn.example.com/somewhere/something.js"></script>
This gives the advantage that if you're accessing it over HTTPS, you get HTTPS automatically, instead of that scary "Insecure elements on this page" warning.
But why use protocol-relative URLs at all? Why not simply use HTTPS always in CDN URLs? After all, an HTTP page has no reason to complain if you decide to load some parts of it over HTTPS.
(This is more specifically for CDNs; almost all CDNs have HTTPS capability. Whereas, your own server may not necessarily have HTTPS.)
Upvotes: 49
Views: 25973
Reputation: 321
Protocol-relative URLs sometimes break JS codes that try to detect location.protocol. They are also not understood by extremely old browsers. If you are developing web services that requires maximum backward-compatibility (i.e. serving crucial emergency information that can be received/sent on slow connections and/or old devices) do not use PRURLs.
Upvotes: 0
Reputation: 1537
There are a number of potential reasons, though they're all not particularly crucial:
Upvotes: 4
Reputation: 1086
One thing to note, if you are using CSP's upgrade-insecure-requests
, you can safely use protocol-agnostic URLs (//example.com
).
Upvotes: 1
Reputation: 31087
As of December 2014, Paul Irish's blog on protocol-relative URLs says:
2014.12.17: Now that SSL is encouraged for everyone and doesn’t have performance concerns, this technique is now an anti-pattern. If the asset you need is available on SSL, then always use the
https://
asset.
Unless you have specific performance concerns (such as the slow mobile network mentioned in Zakjan's answer) you should use https://
to protect your users.
Upvotes: 62