Open thenbe opened 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.
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).
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.
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.