![]() | Ned Batchelder : Blog | Code | Text | Site Http-https transitions and relative URLs » Home : Blog : October 2007 |
Http-https transitions and relative URLsWednesday 17 October 2007 When building a web site with HTTPS pages, one of the annoying tasks is to ensure that those pages make no references to HTTP resources. If they do, then Internet Explorer will pop up alarming messages about mixing secure and insecure content, and do you want to display the insecure content. This confuses users and generally discourages them from continuing to use your site. To fix the problem, all URLs on the page must use HTTPS. Web sites these days are built from reusable components, some of which may be used on both HTTP and HTTPS pages. How to make the URLs correct for both? Relative URLs are the answer. Typically, relative URLs omit the hostname, specifying the full path to the resource, or perhaps just a single path component: <img src='/pix/smiley.jpg' /> Either of these images will display without warning on either HTTP or HTTPS pages. Since the host name is omitted, it uses the host name from the page being displayed. But these URLs also omit the protocol scheme, so the protocol is taken from the base URL also. On an HTTP page, the images will be requested using HTTP, on an HTPPS page, they will use HTTPS. That's why there's no warning, because there's no mixing of secure and insecure content. But what if you need to pull resources from another site? For example, a CDN (content delivery network)? Here the problem seems to be thornier: <img src='http://fast.cdn.net/pix/smiley.jpg' /> If this reference appears in an HTTPS page, the mixed content warning will appear. How to craft a reference that works for both? The answer is again relative URLs, but using a more obscure syntax: <img src='//fast.cdn.net/pix/smiley.jpg' /> Here, we've left off the protocol scheme, but included a host name. In this case, the protocol scheme from the displayed page will be used, but against the host in the URL. The relative URL system is still in play here: omitted portions of the URL at the beginning are taken from the base page, and the relative URL takes over whereever it starts. On an HTTPS page, this will be an HTTPS request to the CDN, on an HTTP page, it will be an HTTP request. You have to be careful to only use this syntax in pages destined for browsers. If you put it in an email, there will be no base page URL to use in resolving the relative URL. In Outlook at least, this URL will be interpreted as a Windows network file, not what you intended. BTW: when trying to get rid of the mixed secure and insecure content warning, you really have to fix up every URL, even if it doesn't seem like it's being used for anything. Flash content? There's a macromedia.com URL in there in the codebase attribute: <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" Making it scheme-relative as shown will also prevent warnings. | |
Comments
Wow, you do learn something every day. I didn't realize that the full url minus the protocol was valid syntax. Interesting.
Thanks! That's damn nice.
BTW, do you know in which HTML version did this appear?
Amazing. I have never seen that syntax before.
Also, Google Analytics provides a secure reference to their .js file as well.
Great ! Thanks very much.
Very clever. Thanks. Also, your previous two posts are fantastic. Here's one more subscriber to your RSS feed.
Which browsers does this work in?
I had no idea about this, though it doesn't work for me...
Would love to see it working. Do you have it running somewhere?
I don't know in which version of HTML it appeared. The HTML 2 spec references RFC 1808 which describes this behavior, and was written in 1995.
I know this syntax works in IE6, IE7, FF2, and Safari 2 and 3. I don't know of any browsers in which it doesn't work.
I think this is not a case of new syntax, but of a specialized and little-used syntax.
dave g: URLs like this are on tabblo.com now. Load the home page and look at the source....
The big downside with relative urls in blog posts is that they never get translated in the outgoing RSS feed.
complete pain in the butt.
Wow - I never realised that. Another snippet for the HTML box of tricks!
clever!
I wish most of the web developers who use https should read this post.
@engtech : The contents of the secure pages are hardly pushed into the RSS feeds anyway. So I don't think that's a big downside.
Very interesting. Could also be used to shirk page file sizes by a few bytes, even on normal HTTP sites.
Oops, shrink, not shirk.
I had no luck with this technique - IIS server refused to serve up the image when referenced this way - main environment was HTTPS, image was on HTTP server.
Does this assume a certain default server or browser setting?
The server settings have nothing to do with it: the resolution of a relative URL into a server request is all done at the browser.
If you install Fiddler, you'll be able to see the requests the browser is making. That should help find the problem.
Ok, I've been building websites since 1996, and I had absolutely no idea about this. I guess you do learn something new every day. :-)
Awesome. I swear I had Saved As New this post in my Bloglines account... but which RSS feed was it? To paraphrase Michael Corleone, "Ned, I knew it was you." Found it, used it, great tip.
Add a comment: