Say we have two containers:
- `app1` with `HTTPS_METHOD=redirect`
- `app2` with `HTTPS_METHOD=nohttps`
Without this change the fallback answer on an HTTPS request to an unknown
server would change depending on whether `app1` is up (503) or not
(connection refused). This is not wanted.
In case someone doesn't want HTTPS at all, they just have to not bind
port 443.
Values:
* `legacy` (default): generate location blocks for ACME HTP Challenge
excepted when `HTTPS_METHOD=noredirect` or there is no certificate for
the domain
* `true`: generate location blocks for ACME HTP Challenge in all cases
* `false`: do not generate location blocks for ACME HTP Challenge
This feature is currently needed because acme-companion may generate
the HTTP Challenge configuration while it was done already by nginx-proxy
(see #2465#issuecomment-2136361373).
Also sometimes a hardcoded ACME challenge location is not wanted because
the challenge validation is not done with acme-companion / Let's Encrypt,
and with a challenge location setup differently.
* chore/doc: explicit policy on missing certificate
This doesn't change the current nginx-proxy behavior, but makes explicit
the current HTTPS_METHOD policy on missing certificate.
* fix: bad wording about missing certificate
Co-authored-by: Nicolas Duchon <nicolas.duchon@gmail.com>
* docs: typo in suggestion
---------
Co-authored-by: Nicolas Duchon <nicolas.duchon@gmail.com>
Without this fix the response of nohttp sites to HTTP requests changes
depending on the existence of at least one HTTP enabled site:
* no HTTP enabled sites -> connection refused
* at least one HTTP enabled site -> 503
This fix ensures the response is always 503.
So that there is no need anymore for the Let's Encrypt companion to fiddle
with vhosts nginx configuration.
When `HTTPS_METHOD=nohttp` and the certificate is missing, enforce nohttp
instead of switching to `HTTPS_METHOD=redirect`.
For containers grouped by identical VIRTUAL_HOST,
those with no VIRTUAL_PATH variable were silently discarded
when at least one container with VIRTUAL_PATH existed.
(See nginx-proxy/nginx-proxy#1504)
Using variable VIRTUAL_HOST_MULTIPORTS as a dictionnary:
key: hostname
value: dictionnary:
key: path
value: struct
port
dest
When the dictionnary associated with a hostname is empty, default values
apply:
path = "/"
port = default port
dest = ""
For each path entry, port and dest are optionnal and are assigned default
values when missing.
Example:
VIRTUAL_HOST_MULTIPORTS: |
host1.example.org:
"/":
port: 8000
"/somewhere":
port: 9000
dest: "/elsewhere"
host2.example.org:
host3.example.org:
"/inner/path":
Introduces 3 new environmental variables:
- `LOG_FORMAT`
- `LOG_FORMAT_ESCAPE`
- `LOG_JSON`
`LOG_FORMAT` and `LOG_FORMAT_ESCAPE` default to standard values.
When `LOG_JSON` is set, defaults are changed to: `{"time_local":"$time_iso8601","client_ip":"$http_x_forwarded_for","remote_addr":"$remote_addr","request":"$request","status":"$status","body_bytes_sent":"$body_bytes_sent","request_time":"$request_time","upstream_response_time":"$upstream_response_time","upstream_addr":"$upstream_addr","http_referrer":"$http_referer","http_user_agent":"$http_user_agent","request_id":"$request_id"}`and `json`.
See `nginx.tmpl` and https://nginx.org/en/docs/http/ngx_http_log_module.html#log_format for details
