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.
Rationale for eliminating the check to see if the `DEBUG` environment
variable holds a true value:
* The `DEBUG` environment variable might be set on a container (for
purposes specific to that container, not `nginx-proxy`) to a value
that cannot be parsed as a bool, which would break `nginx-proxy`.
* It simplifies the template.
* It eliminates a cold code path.
* It avoids heisenbugs.
* It makes debugging easier for users.
Also delete the debug info tests, as they are fragile and they provide
limited value.
Alternatively, we could avoid collision with the container's use of
the `DEBUG` environment variable by using a container label [1] such
as `com.google.nginx-proxy.nginx-proxy.debug`. I think doing so has
dubious value, especially if we want to attempt backwards
compatibility with the `DEBUG` environment variable.
Fixes#2139
[1] https://docs.docker.com/engine/reference/commandline/run/#-set-metadata-on-container--l---label---label-file
Co-authored-by: Nicolas Duchon <nicolas.duchon@gmail.com>
