Are there cases where Protocol-Relative URLs is preferred over HTTPS?

914 views Asked by At

Protocal-relative URLs

Protocol-relative URLs are URLs that begin with //, instead of http:// or https://. The actual protocol used to load the resource is derived from the containing page; Therefore, //example.com/smile.jpeg in an HTTPS page will load https://example.com/smile.jpeg.

Anti-pattern claim

It has been widely claimed that Protocol-relative URLs should be completely abandoned in favor of HTTPS; one of my recent pull requests was rejected do that claimed (and eventually accepted with HTTPS only).

The problem

Many reputable services on the web still use Protocol-relative URLs. For example, Google Analytics calls //www.google-analytics.com/analytics.js, and Disqus calls //EXAMPLE.disqus.com/embed.js.

Is there a reason why web services still use the insecure Protocol-relative URLs instead of HTTPS?

2

There are 2 answers

4
Todd Knarr On

Because the services might not be called via HTTP at all? Take a look at the list of IANA-registered URI schemes. By using a protocol-relative URL it allows the page to be loaded by any scheme that allows the same syntax.

Protocol-relative URLs also allow control of the scheme to be done in the server configuration as opposed to the page-generation code or the page templates. If protocol-relative URLs are used the Web server can be configured to forcibly redirect any plain http: request to an https: equivalent and typos in the page templates or code can't accidentally use http: (or if they do, it's easy to scan the code and template files and find all occurrences of the problem).

0
Joe Fletcher On

If the asset is available via https, there is no reason to use protocol relative URLs. Specifying https is inherently more secure than leaving it open-ended, which provides the opportunity for an insecure http to be injected. Performance is not a reason (ref: https://istlsfastyet.com/).

It is only a matter of time that those services you mention will switch to https-only protocols: it's in their best interests to consolidate around a single protocol/URL and to only provide securely delivered assets.