Last week, I fixed an interesting issue and want to share it with you.
It first came from a bug report when a user found that one of the PDF's logos was missing. Because we use wickedpdf to generate PDFs, naturally, the first thing I did was open the html we serve to wickedpdf in the browser. And guess what, the logo was showing correctly in my browser. That is strange, so I open the html template and check the source code, and what I found was something like this:
<img src='//remotesite.com/img/logo' />
Notice that the image url does not have a protocol, is it even a valid URL? It turns out that it is, this type of url was official named as network-path reference in rfc3986 section 4.2. Paul Irish wrote a blog post to introduce it back in 2010 and give it a better name: Protocol Relative URL .
As the name suggests, with protocol relative URLs, the resource is requested base on the current page's protocol, so if the current page is using
http then the resource will also be requested with the
http protocol; and if the current page is using
https, then the resource is requested with the
Since the protocol-relative URL is so easy to use and it works well in most of the browsers (except for IE6, but nothing works well in IE6), Paul Irish used it in html5-boilerplate, and many people adopted it to avoid the mixed active content issue especially when trying to move their site from http to https.
Although most modern browsers support Protocol Relative URLs, they don't work as expected with wickedpdf. Before calling wickedpdf, a html file is saved in local storage, and wicked_pdf serves the file to wkhtmltopdf. Wkhtmltopdf considers it as a local file and automatically uses a
file:/// protocol to reference assets. This causes problems because the resources aren't always on the local server. Sometimes they are served from a CDN or from online storage such as S3.
For the same reason, the following scenarios also will not work:
- A user tries to save a HTML page that contains Protocol Relative URLs and then opens it in the browser
- A user is sent a HTML email that contains Protocol Relative URLs and they try to open it in an email client such as Outlook
- Using background jobs to generate HTML files containing Protocol Relative URLs
Also, we found that Protocol Relative URLs cause issues with third party integrations (such as oauth via Facebook and Twitter) that expect the protocol. Here is an example from the internet:
This person tried to share a page containing images with protocol relative urls:
But Facebook didn't pick up the images on the page:
After adding the protocol to the images
Facebook displayed the images correctly:
Qt Webkit hasn't supported Protocol Relative URLs since version 0.9.6, so any library that relies on Qt Webkit basically won't work with Protocol Relative URLs.
It looks like they do more harm than good, right? So how did we fix this problem in the end? Simple, we stopped using Protocol Relative URLs, and updated the code to always use HTTPS protocol for external assets.
All of the links like this:
<img src='//remotesite.com/img/logo' />
are now changed to:
<img src='https://remotesite.com/img/logo' />
It should be a fairly trivial shift as most CDNs allow HTTPS request nowadays, and SSL is fast enough in most scenarios. It also provides a more secure way to get the assets. So there is no reason to continue using Protocol Relative URLs anymore.
Finally, let's end with Paul Irish's update from the same Protocol Relative blog post:
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.
Receiving and processing inbound emails with Action Mailbox an...
Simple CSS Dark Theming for Accessibility
How structure and process are the most important things we del...
reinteractive is Australia’s largest dedicated Ruby on Rails development company. We don’t cut corners and we know what we are doing.
We are an organisation made up of amazing individuals and we take pride in our team. We are 100% remote work enabling us to choose the best talent no matter which part of the country they live in. reinteractive is dedicated to making it a great place for any developer to work.
Webinars are our online portal for tips, tricks and lessons learned in everything we do. Make the most of this free resource to help you become a better developer.
The Ruby on Rails Installfest includes a full setup of your development environment and step-by-step instructions on how to build your first app hosted on Heroku. Over 1,800 attendees to date and counting.
The Ruby on Rails Development Hub is a monthly event where you will get the chance to spend time with our team and others in the community to improve and hone your Ruby on Rails skills.