search

caddyserver / caddy

Fast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS
https://caddyserver.com
Apache License 2.0
58.02k stars 4.03k forks source link

Fail when environment variables were expected but not provided #6444

Open thenbe opened 3 months ago

thenbe commented 3 months ago

Hi. This is a continuation of #2815.

tldr; I know we can use default environment variables to fall back on, but I'm looking for something similar to bash's set -u: (Treat unset variables as an error when substituting), which keeps being a lifesaver.

mholt commented 3 months ago

The big problem/question is, what are we going to do about it? It's too late, by the time most placeholders are evaluated, to do anything with the error. Fail the request whose handler uses the placeholder? I'm not really sure how useful it will be since placeholders are evaluated at runtime.

thenbe commented 3 months ago

I'm probably missing a ton context, but I was simply thinking that when we try to substitute an env var before parsing, such as the one declared in this example, and that variable does not exist in the environment, then we could behave just like we would if that config file contained a syntax error (outright fail to start or exit).

mholt commented 3 months ago

Ah, you mean Caddyfile placeholders? {$VAR} is evaluated when the Caddyfile is adapted to JSON. {env.VAR} is what it gets adapted to and is evaluated at runtime.

The problem is that sometimes an empty variable is expected. So we can't always crash in that case.