Force SSL with permanent redirect instead of temporary redirect?

The very handy c::set('ssl',true); redirects all requests to HTTPS (docs). It does this with a HTTP redirect 302 ‘Moved Temporarily’. Is there a way to do the same but with a HTTP redirect 301 ‘Moved Permanently’?

In my specific case the reason is that iTunes doesn’t like a podcast feed URL with a status code of 302. But I imagine that most people would like their redirect to be permanent? (I’m not up to date when it comes to SEO but it seems intuitive to tell robots that the HTTPS address is here to stay.)

1 Like

The easy way would be to redirect in the .htaccess file:

# https redirect
RewriteCond %{HTTPS} !=on
RewriteCond %{ENV:HTTPS} !=on
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]

But keep in mind, that (as I head of) iTunes is not compatible with quite modern TLS certificates. Have you tried, that iTunes likes your certificate?

Good point, no, I haven’t.

My feed got deleted from iTunes without notice. I was assuming this was because of the 302 redirect. Their docs say you should use a 301 redirect. But maybe you’re on to something and the certificate is the problem.

Do you know how I can find out whether the certificate is the problem? (I already sent an email to Apple Podcast support but I assume they will need a couple of days to respond.)

I only heard of issues with some certificates or TLS setting at some german podcast (bitsundso or freakshow). There are issues, because all the iTunes backend is based on WebObjects and Java 5 or 6. I don’t know the details, but it’s a quite old version of java.

I use a certificate from Let’s Encrypt which may be the root of the problem. For everyone who is interested, here’s a thread in german podcasting forum Sendegate on the matter. Thanks @jbeyerstedt for pointing me in this direction!

I’ll wait for a response from Apple and report back. Depending on the answer my original question (how to force SSL with permanent redirect instead of temporary redirect) may or may not be obsolete.

If you use Let’s Encrypt then that’s definitely the main issue here.

FYI: Kirby uses the 302 redirect because 301 is always final. It gets cached and there are sometimes situations where people are like “I just wanted to try TLS and now I can’t get back without strange issues”. So it makes sense to do it via .htaccess like @jbeyerstedt proposed.

1 Like

Digging in the forum…

How would you redirect both http to https and www to non-www?
I’m struggling to find the right order/combo.

You can use two separate rules in combination. The result will be two redirections in the worst case, but that’s fine. :slight_smile:

1 Like