This is not true.
- The links I attached in the comment above was from a
git blame. Here is the latest version of the file (relevant line linked): discourse_docker/templates/web.ssl.template.yml at 247c71a1e45d32b0b814a8e9d5fdaa4faaf727b9 · discourse/discourse_docker · GitHub - My friend’s new site install was from a week ago. Line 37 of the template above reads:
return 301 https://${DISCOURSE_HOSTNAME}$request_uri;but in the Discourse Docker container, both her (and my)/etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.confreadsreturn 301 https://<our_discourse_site>;Notice how$request_uriis stripped. Something is causing that to vanish! (I don’t know what). - I did a simulated forced renewal this morning as part of my investigation. It failed. I then changed
/etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf. It succeeded!
This is actually ok; I’ll just manually edit 20-redirect-http-to-https.conf every time I update Discourse. For those stumbling on this comment, the command to run is:
cat > /etc/nginx/conf.d/outlets/before-server/20-redirect-http-to-https.conf << 'EOF'
server {
listen 80;
listen [::]:80;
location ~ /.well-known {
root /var/www/discourse/public;
allow all;
}
location / {
return 301 https://<YOUR_FORUM_ADDRESS>$request_uri;
}
}
EOF
I’m not entirely sure what is causing this failure, but I know modifying the conf above fixes it. But I’ve also modified notifs so that letsencrypt renewals no longer fails silently — so I can have some advanced warning. Just thought you’d like to know!