Before, if a site's certificate was not found, the site was served
over http rather than https. Failing open like this is problematic
for sites where security is important. Presumably the user set
`HTTPS_METHOD` to a non-`noredirect` value (or left it unset) for a
good reason; we should honor it even if it means serving error
messages.
WARNING: This change breaks compatibility. Any vhost where all of the
following are true will fail after this change:
* `HTTPS_METHOD` is either unset or set to a value other than
`nohttps`.
* The vhost does not have its own certificate (`default.crt` doesn't
count).
* Clients expect to be able to access the vhost by using plain http
to nginx-proxy.
To get the previous behavior, set `HTTPS_METHOD` to `nohttps` for the
vhost.
Before, a fallback http server was created to handle requests for
unknown virtual hosts even when `HTTPS_METHOD=nohttp`. (In this case,
all http vhosts would be unknown.) Likewise, a catch-all fallback
https server was still created even if `HTTPS_METHOD=nohttps`.
Now the fallback servers are created only if needed. This brings the
behavior in line with the documentation and user expectation. It will
also make it easier to implement a planned feature: different servers
on different ports.
Before, if neither the vhost-specific cert nor `default.crt` existed,
nginx-proxy would not create the https vhost. This resulted in nginx
either refusing the connection or serving the wrong vhost depending on
whether there was another https vhost with a certificate.
Now nginx-proxy always creates an https server for a vhost, even if
the vhost-specific certificate and the default certificate are both
missing. When both certs are missing, nginx is given empty
certificate data to make it possible for it to start up without an
error. The empty certificate data causes the user to see a TLS error,
which is much easier to troubleshoot than a connection refused error
or serving the wrong vhost.
