46

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

oink
  • 1,443
  • 2
  • 14
  • 23

5 Answers5

57

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.

Joe
  • 29,416
  • 12
  • 68
  • 88
7

Because of performance. Establishing of HTTPS connection takes much longer time than HTTP, TLS handshake adds latency delay up to 2 RTTs. You can notice it on mobile networks. So it is better not to use HTTPS asset URLs, if you don't need it.

zakjan
  • 2,391
  • 1
  • 19
  • 29
  • I say it's better to use https cuz of http2 performance and it's more secure! – Endless May 14 '17 at 16:47
  • 9
    This is 2 years old answer, when HTTP2 was not available yet. – zakjan May 23 '17 at 12:42
  • 7
    This answer is no longer true. Enable HTTP2 on your websites and HTTPS is faster than HTTP. – Qwertie Jan 16 '18 at 04:31
  • 3
    As you should definitely know by now, it is not that HTTPS is now faster than HTTP, it's that HTTP is now faster than older HTTP, and only the HTTPS version of it has been implemented at all. HTTPS is still and always will be necessarily slower than HTTP. – Jan Kyu Peblik Nov 15 '18 at 17:12
  • Note that //: links are ruined when the page is saved offline. https://joonas.fi/2016/12/27/stop-using-protocol-relative-urls/ – Dan Jacobson Nov 23 '19 at 02:49
  • http2 enables multiple request, it doesn't magically make ssl handshake disappear. give source otherwise. if you have a static page that has nothing secret enough to be encrypted then it make sense you'd want to optimize for speed and that would mean NO ssl for that page – Muhammad Umer Jan 15 '20 at 19:10
3

There are a number of potential reasons, though they're all not particularly crucial:

  • How about the next time every business with an agenda pushes a new protocol? Are we going to have to swap out thousands of strings again then? No thanks.
  • HTTPS is slower than HTTP of same version
  • If any of the notes listed at caniuse.com for HTTP/2 are a problem
  • Conceptually, if the server enforces the protocol, there is no reason to be specific about it in the first place. Agnosticism is what it is. It's covering all your bases.
Jan Kyu Peblik
  • 1,435
  • 14
  • 20
1

One thing to note, if you are using CSP's upgrade-insecure-requests, you can safely use protocol-agnostic URLs (//example.com).

Null
  • 975
  • 13
  • 13
0

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.

KHAYRI R.R. WOULFE
  • 189
  • 2
  • 5