FYI - "https-only" mode does not work the way you think it does ;) The site is hard to access on such browsers only because it actually does serve something over HTTPS - however, it's just an error page there.

Just because there is something on this domain listening on :443 and serving HTTPS, doesn't mean it has to serve the same content as the HTTP on :80, or even work at all.

Always-redirect-to-HTTPs plugins _are_ broken by assuming otherwise.

> doesn't mean it has to serve the same content as the HTTP

Of course, that's the exact reason I wrote the original comment.

Author here. I took a look in IIS Admin and is unable to see WHERE did I ask it to serve https. I thought I was http only. The bindings only say http, both for the bef.no site and for the 'Default Web Site'.

Broken is in the eye of the beholder. Why the hard stance?

These plugins are based on a wrong assumption that the scheme is not an important part of the url. For some urls, the assumption works; for others, it doesn't and the result is an interminable stream of messages complaining that something is broken. The thing that is broken is the assumption.

Are we still arguing for HTTP-only sites ?

I would link to implement https since almost all other sites I surf on now are https by default.

But the last time I tried it with multiple domains pointing to the same server it was too cumbersome.

And having to renew the certificate is also not very appealing for a small hobby site.

The last two are solved with modern software and with the ACME protocol. Just use Caddy, it's the easiest way to host HTTPS websites.