oink
oink

Reputation: 1503

Why use protocol-relative URLs at all?

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

Answers (5)

KHAYRI R.R. WOULFE
KHAYRI R.R. WOULFE

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

Jan Kyu Peblik
Jan Kyu Peblik

Reputation: 1537

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.

Upvotes: 4

Null
Null

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

Joe
Joe

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

zakjan
zakjan

Reputation: 2559

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.

Upvotes: 7

Related Questions