Prefer HTTPS for readthedocs.io domains

[gwillem]

Details

• Project URL: http://docs.readthedocs.io/en/latest/

Could we have default/preferred RTD HTTPS urls? As major browsers increasingly deprecate non-HTTPS content. Also, we cannot overwrite the current HTTP canonical url, as it is inserted by RTD at the end of the section.

Expected Result

I would expect:

1. To get 301 redirected to the https version.
2. To have the https url as canonical url in the HTML.

Actual Result

PS. Thanks for making a great service!

[codelucas]

Anyone working on this one? Seems important as browsers deprecate non https

[ericholscher]

+1 on this. I think it will be a multi-step process, but we should get started with it. The primary thing we want to avoid is linking to https pages when those pages have http images or similar, causing mixed content warnings. I think that might just be part of the process of the migration, but here is my thoughts:

• We start linking "View Docs" and similar to HTTPS for projects on readthedocs.io domains, and see what happens, if it breaks much
• We start redirecting HTTP -> HTTPS on readthedocs.io domains for projects.
• We implement letsencrypt certs for CNAME's that we host
• We start linking "View Docs" on CNAME's that we have a cert for with HTTPS
• We start auto-redirecting HTTP -> HTTPS for CNAME's

[edmorley]

The primary thing we want to avoid is linking to https pages when those pages have http images or similar, causing mixed content warnings.

The upgrade-insecure-requests CSP directive may help reduce the breakage:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests
https://community.akamai.com/community/web-performance/blog/2017/02/10/how-to-auto-upgrade-to-https-aka-avoid-mixed-content

(or at least provide a way to see what would break, via Content-Security-Policy-Report-Only)

[agjohnson]

I agree with the steps laid out here. I'm going repurpose this task to deal with just readthedocs.io domains, as the other steps are mostly operations changes. I'll open up corresponding issues on our server provisioning repositories to deal with those.

[davidfischer]

This is going live next week

[davidfischer]

Just to give a small update here, this is partially live. We deployed a change such that all "view docs" links on Read the Docs will now have an HTTPS link. However, we are not yet issuing a redirect. That change will probably go live this week as a 302 redirect. If all goes well, we will update that to a 301 redirect.

[dmalan]

Hi @davidfischer, all, just wanted to check if deployment of 302 (or 301) redirects is still pending for docs using non-custom subdomain.readthedocs.io URLs? Is there any way we can induce on our end in the meantime, as via .readthedocs.yml or such? Afraid I only saw HTTPS settings under Admin for custom domains. Thank you!

[davidfischer]

Afraid I only saw HTTPS settings under Admin for custom domains.

Currently all this check box does is ensure that the link generated for custom domains is HTTPS. This is already the case for all *.readthedocs.io sites.

[dmalan]

Ah, are there still plans to issue 302 (or 301) redirects for visits to http://*.readthedocs.io/*?

[davidfischer]

Ah, are there still plans to issue 302 (or 301) redirects for visits to http://*.readthedocs.io/*?

Yes. I have an open PR for this in our operations repo and I just need to guide it through review and deployment. Sorry it's taking so long.

[davidfischer]

Thanks for reminding me. This is live as a 302.

[davidfischer]

I'm going to make a PR right now that changes the 302 to a 301 but my plan is to not merge that for a couple weeks to a month in case I see any reported issues.

I'm closing this though as we are now redirecting.

[davidfischer]

We start auto-redirecting HTTP -> HTTPS for CNAME's

The last step of this 5 step plan is being tracked in #2652. This is a bit trickier as it requires a database lookup or API call to know if we have a certificate for any specific domain.

[dmalan]

Thanks very much! Working well so far!