The file that never arrived

A redirect that wasn't firing.

.htaccess handles canonicalisation on this site: http to https, and dropping www — so all traffic lands on exactly one address instead of spreading across four variants. At some point that redirect simply wasn't working: http:// just stayed http://.

The first diagnosis focused on the wrong signals: the rule checked %{HTTPS} and a proxy header, with logic requiring both to say 'not https' before anything happened. Strato's own documentation showed their platform actually uses %{SERVER_PORT} to distinguish http/https — so the rule was rewritten around that. Logical, well-reasoned, and... it fixed nothing.

The real cause: the file never arrived.

So the rule itself was never the problem — it had simply never been able to show it, because .htaccess never reached the server at all. The deploy action ships files with a simple ./dist/* pattern, and just like in a plain shell, a bare * doesn't match files starting with a dot. Every change to .htaccess in the repo, going back weeks, had therefore been silently dead on production.

No error message helped: the deploy itself succeeded, every time, just without that one file. Exactly the kind of mistake that stays unnoticed for a long time, because everything looks green until you happen to test what's actually live on production.

The fix, and the lesson.

The fix: a separate deploy step, just for that one file, with an explicit path instead of a pattern — a form the deploy action already supports, so no workaround needed. After that step, confirmed on the real production environment: the redirect works, finally proven instead of assumed.

The first fix wasn't wrong — only the assumption was. Sometimes the problem isn't the rule you're adjusting, but the fact that it never arrives anywhere.