feat: HTTP -> HTTPS redirects on all site configs #26
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR changes the default behavior for setting up HTTP to HTTPS redirects. Previously, the redirects would only be set up if Casket was managing the TLS (it qualifies for automatic HTTPS).
Background
The conventional advice for servers using their own certificates or
tls self_signed
was to set up a redirect rule manually, like so:This is fine for one-off deployments, but when doing this for many domains, it becomes more appropriate to use a template. So, one might try:
However, if the site that imports the template already has a redirect rule for
/
, this configuration will conflict. Thus, the desire to change the default behavior.Solution
With this PR, all sites that have TLS enabled in any way will have a redirect created on the HTTP port. This is potentially a breaking change; if a configuration already assumes that nothing would be bound on port 80. To disable this behavior, you can now opt-out of the redirect creation per-site (even if the site qualifies for automatic HTTPS like before):