Overview#

HTTP-HTTPS transitions and relative URLs#

When building a website with HTTPS pages, one of the annoying tasks is to ensure that those pages make no references to HTTP resources. If they do, then browsers may 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' />
    <img src='smiley.jpg' />

Either of these images will display without warning on either HTTP or HTTPS pages. Since the hostname is omitted, it uses the hostname 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 HTTPS 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 wherever 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" 
       codebase="//download.macromedia.com/pub/shockwave/cabs/flash/blah#blah"
       width="600" height="400"> ... </object>
Making it scheme-relative as shown will also prevent warnings.

Novell Access Manager#

When Using Novell Access Manager, it is important to understand how HTTPS works.

More Information#

There might be more information for this subject on one of the following:

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-4) was last changed on 04-Jan-2017 09:36 by jim