Forums

I have a site where I force https with SECURE_SSL_REDIRECT = True, so when I request the site I want the browser to redirect to https://www.mydomain.com. It almost works for every of these URLs:

• http://www.mydomain.com --> OK!
• http://mydomain.com --> OK!
• https://www.mydomain.com --> OK!
• https://mydomain.com --> NOT OK! (unable to connect)

In the DNS settings I have a A-record that redirects from mydomain.com to www.mydomain.com.

How can I make the last one work?

I would start by comparing the IP addresses of 'www.mydomain.com' and 'mydomain.com'. Maybe it's related to PA recommendation to use CNAME instead of A-record. This can be a problem with some DNS providers, who offer only one CNAME-record.

Also some browsers like to add 'www.' prefix for you (and even '.com' suffix sometimes). You can check that by sniffing (http only) or with Network-pane in browser Dev-tools (https also).

Another possibility - you said "A-record that redirects", could this mean - that your DNS registrar are doing a HTTP 302 redirection (not DNS redirection/resolving) for your naked domain (processing such requests by their dedicated webserver which doesn't handle https)?

www.mydomain.com and mydomain.com has different IP-adresses.

The A-record that I added is a "URLforward" record that does a 301 from mydomain.com to www.mydomain.com. Is that wrong? I read this and thought that a "redirection service" was the same as such a URLforward (forgive me for being a newbie on DNS settings).

This is the output from the dev tools:

• http://www.mydomain.com --> 301 followed by 200
• http://mydomain.com --> 301 then 301 then 200
• https://www.mydomain.com --> 200
• https://mydomain.com --> No status code

Yes, you're right, it's the same URLforward. That's excellent article on subject. And wow, since last time I checked, it's updated with great info about https problems. Thanks to Harry Percival!

The problem with current setup is - your DNS provider can't offer a https redirection (only http) because they don't have a SSL cert and key for your naked domain. Tho, theoretically they could, if they had an option for you to upload a separate set of cert/key (because those can differ from full domain cert/key - which you should only upload to the main Django site at PA).

You should decide: do you really need a working site also at https://mydomain.com/[any-path], or use it only for short (http:// only) easy urls (for people to type in address-bar). Also there is a question about path-redirections ([any-path] part) to https://www.mydomain.com/[any-path] (which may not be supported by your DNS's URLforward).

Agreed with everything @Astronoms says above :-) We do indeed suggest that you not worry about https://mydomain.com. The way people will come to your website is normally by typing either "mydomain.com" or "www.mydomain.com" into their browser's address bar, and both of those will work because the browser will just prepend http:// and hit that site, which will, one way or the other, redirect to your real site.

Just as proof that we honestly don't think that https://mydomain.com is that important, if you check out our own site you'll see that https://pythonanywhere.com doesn't work. It's never been a problem for us.

Thank you for your input, guys. You are probably right that https://mydomain.com is not important because of the way browsers work. In any case, it would be nice to have it working. So, are you arguing that this is a limit in the way PA works or a limit in the way my particular DNS provider works?

Astronoms, I am not sure what you mean with regards to path-redirections? It seems to work (except for https://mydomain.com/some-path of course):

• http://www.mydomain.com/some-path --> https://www.mydomain.com/some-path
• http://mydomain.com/some-path --> https://www.mydomain.com/some-path
• https://www.mydomain.com/some-path --> https://www.mydomain.com/some-path
• https://mydomain.com/some-path --> Not working

So, are you arguing that this is a limit in the way PA works or a limit in the way my particular DNS provider works?

To be fair, it's a limit on both.

Your DNS provider is giving you a free way to redirect your HTTP traffic from mydomain.com to www.mydomain.com. But they're not providing you with a way to redirect HTTPS. That's pretty much true of all DNS providers, not just of yours. I can't think of any offhand that do support HTTPS for redirects.

On PythonAnyhere, you can set up a redirection website that serves mydomain.com, so you could set something up that mirrors what your DNS provider does, but could also handle HTTPS. However, because it would be running as a website under your PythonAnywhere account, it would cost money (unlike the free -- or at least, bundled with the price of the domain -- option with your DNS provider).

Yes, by path-redirection I meant that: not only domain-part of URL is redirected, but also the requested path+query. But keep in mind, it's a bit more complicated, than simple domain redirect (when regardless of what the browser is requesting, send them to www.mydomain.com/). Because the path+query can contain some allowed chars, but some chars are prohibited or even can be dangerous. So the redirection app needs to filter out - which characters it should include in "Location:" header when doing its "simple" work.

I can add to what @giles suggested, that you will also need a ssl cert+key pair for your naked domain! Do you have one? Maybe you have an asterisk one (generated for *.mydomain.com) - that will work. And if you are using a free ones from letsencrypt, you will also need to extend your small redirection app to work with letsencrypt's update script (dehydrated or similar)!

Duplicated comment, removed ;)

LOL, I didn't know how to escape an asterisk in Markdown :) So my comment was on hold for too many edits...