Why Protocol-Relative URLs are Considered Anti-Pattern?
It's because protocol-relative URLs may resolve the resource to use HTTP or HTTPS depending on the server configuration and/or how the page was accessed. Since HTTP is not secure, it is not recommended to use it anymore; the recommendation now is to use HTTPS instead (as it is far more secure than using HTTP). Besides security implications of using HTTP, it may also not be future-proof, as many new features might only work if SSL is enabled. Therefore, it makes little sense to use protocol-relative URLs or HTTP moving forward.
Why Were Protocol-Relative URLs Used?
Using protocol-relative URLs provided a convenient way to resolve to either HTTP or HTTPS, for example by creating a link in an HTML document without a specific protocol like so:
<a href="//example.com/some/resource">Example</a>
The above resource would resolve to either http://example.com/some/resource or https://example.com/some/resource depending on whether the website was accessed with HTTP or HTTPS.
Prior to using protocol-relative URLs, there were situations where a website might be accessed over one protocol but might be loading some resources over another protocol. For instance, when a website may have been served over HTTPS but static assets were loaded over HTTP. In such cases, the browsers would complain about websites loading mixed content. Therefore, protocol-relative URLs became a popular solution for such scenarios, and were widely used at one point.
This post was published by Daniyal Hamid. Daniyal currently works as the Head of Engineering in Germany and has 20+ years of experience in software engineering, design and marketing. Please show your love and support by sharing this post.