This may not be a good idea. There might be different situations where you want to pick different protocols for the same page.

Needs thought.

Good point. Maybe a disable_https_redirect (or something similar) specification in the URL in the event one does not want an HTTPS redirect?

Currently we're solving this via documenting some sample redirect rules in tut_security.

Implemented in v10 behind hidden 'access_protocol_redirect' option.

Actually we could try and implement the redirection in a little standalone PHP file, and use an installation option rather than a hidden option. And then update the security tutorial to reference that.
The option would define a list of situations to do redirects, e.g. 'protocol,domain'.

We need to consider that all these kinds of redirects we have will not work when serving from the static cache.
So .htaccess equivalents may still be needed, and we need to think how we should handle that - maybe through documentation under static caching.

Note that 'Strict-Transport-Security' should not be used by Composr as it would be assuming Composr controls a whole domain (this is a domain-level upgrade signal).

This is now implemented.

Complicating factors resolved as follows:
1) What if we're behind a proxy and therefore cannot detect if SSL is being used in a normal way? We respect the 'X-Forwarded-Proto' header and trust it only if we validate the proxy caller successfully.
2) What if a page needs to be accessed sometimes HTTPS and sometimes not? I don't think that's a real use case. The use case is some pages may be HTTPS and some not, as per the 'ssl' addon. We will do forwarding based on correct identifying of what the page should be, checking both the base URL and the SSL configuration for the page (if the 'ssl' addon is installed). We cannot use a URL flag, as the HTTP->HTTPS URL redirection is a security feature and we cannot trust the calling URL parameters.
3) What about the static cache? The redirection code now runs early, it is no longer in site.php. The only issue is that the SSL addon configuration cannot be respected, leading to no redirects for individually enabled SSL pages when served via static cache. This seems an insignificant corner case.
4) While 'Strict-Transport-Security' cannot be used, it is now documented that a user can enable it in their web config (including how).
5) Redirects may also happen due to CSP. This remains documented. We do not rely on it, as we should not assume every web client has CSP available (especially things like wget).

I have removed the hidden 'access_protocol_redirect' option as it is not needed, and use of that prevented us moving the redirection code out of site.php.