Mixed Content with Pelican

3
votes

TL;DR

My Pelican blog is served through HTTPS but CSSs are not loaded because of "mixed content", even though they appear in the page source as HTTPS.

Context

I have a Pelican blog hosted on GitHub pages. I have a CNAME record for a custom domain to point to this blog.

The aim

I'm trying to achieve serving this blog with HTTPS, which is possible with CloudFlare (GitHub support told me it's the only solution at the moment).

The problem

After setting everything as indicated, I can access my blog securely but CSSs are not loaded because they are indicated as mixed content.

Console errors

However, when I look at the page source, all CSSs should be served with HTTPS (as it's included with protocol-relative URLs):

<head>
    <meta charset="utf-8">
    ...
    <link href="//nonatomiclabs.github.io/theme/css/ipython.css" rel="stylesheet">
    <link href="//nonatomiclabs.github.io/theme/css/bootstrap.min.css" rel="stylesheet">
    <link href="//maxcdn.bootstrapcdn.com/font-awesome/4.1.0/css/font-awesome.min.css" rel="stylesheet">
    <link href="//nonatomiclabs.github.io/theme/css/local.css" rel="stylesheet">
    <link href="//nonatomiclabs.github.io/theme/css/pygments.css" rel="stylesheet">
</head>

I have tried setting Pelican SITEURL variable to both //nonatomiclabs.github.io and https://nonatomiclabs.github.io and this does not change anything (so the problem is not due to the use of protocol-relative URLs).

CloudFlare also has an "Automatic HTTPS Rewrites" feature which is supposed to get rid/reduce mixed content problems but does not help in my case.

Questions

  1. How is it possible that the browser (both Chrome and Safari at least) shows the page source with HTTPS or protocol-relative URLs but that those seem not to be respected?
  2. Who is "responsible" for the problem? Pelican, CloudFlare, the browser, etc.?
  3. How to solve the problem?

If one needs to see the code:

1
httpscloudflarepelican

1 Answers

3
votes

Answers to your questions:

  1. It's most likely not that browsers aren't respecting the HTTPS URLs, but that the domain re-direction is resulting in unencrypted HTTP links.

  2. Some combination of GitHub Pages, CloudFlare, and associated domain re-direction is most likely the cause of the problem.

  3. Potential solutions follow below.

First, try explicitly prepending the static asset links with https: inside your HTML instead of relying on the SITEURL setting and see whether anything changes.

Second, the only resources that are failing are those that begin with https://nonatomiclabs.github.io — it seems that requests to that domain are being re-directed to https://www.nonatomiclabs.com, and that re-direction could be the cause of the problem. Try using a domain that does not re-direct. For example:

<link href="https://www.nonatomiclabs.com/theme/css/local.css" rel="stylesheet">
[...]

For what it's worth, for my personal Justin Mayer site, my base.html template's CSS links look similar to yours. I set my SITEURL setting to https://justinmayer.com in my publishconf.py settings file, and the resulting output contains proper, fully-qualified links (i.e., not protocol-relative links) that do not yield mixed content warnings.

As an aside, protocol-relative URLs are considered to be an anti-pattern, as they are essentially obsolete in a world of ubiquitous TLS, particularly when Google Chrome 68 marks all unencrypted HTTP requests as insecure this coming July.)

As another side note, there are indications that GitHub Pages might soon support HTTPS, so you may eventually be able to serve your site over HTTPS without CloudFlare.