Does this need to be done only for start-dev with localhost, or does quarkus consider all addresses (0.0.0.0) to be a local address?

@shawkins the filter auto-enables only when quarkus.http.host is localhost, 127.0.0.1, or [::1]. In practice this means start-dev and I guess the case of someone explicitly setting --http-host to one of those three values in production.

@shawkins the filter auto-enables only when quarkus.http.host is localhost, 127.0.0.1, or [::1]. In practice this means start-dev and I guess the case of someone explicitly setting --http-host to one of those three values in production.

Seems best then to limit disabling this validation to just dev mode.

Seems best then to limit disabling this validation to just dev mode.

I considered that earlier, but what about --http-host=127.0.0.1 behind a reverse proxy prod setup? The filter would auto-enable and silently reject forwarded Host headers with 400 and an empty body. Or am I missing something?

Seems best then to limit disabling this validation to just dev mode.

I considered that earlier, but what about --http-host=127.0.0.1 behind a reverse proxy prod setup? The filter would auto-enable and silently reject forwarded Host headers with 400 and an empty body. Or am I missing something?

I would have thought that if quarkus.http.proxy.trusted-proxies="local address" - that this check would be disabled automatically (with the presumption that all access goes via the proxy). Instead it appears they either want you to disable the check or to enumerate all of the allowed hosts - https://github.com/quarkusio/quarkus/pull/55431/changes#diff-f2164492a3441f479e494066c371b9a4bfc8bf3c67a4129cdd118bd22b975df4R462

So either we can be opinionated and require users when using the http host = localhost to also set trusted-proxies to localhost (which could be a breaking change), or we should leave this check as disabled like you are doing.

Probably worth calling out that this new quarkus validation is highly related to #50602 - in particular to the PR that @ahus1 opened. However returning a 400 is not a good approach specifically for misdirected requests. I think there needs to be more discussion on how misdirected requests could be handled upstream - I'll open a quarkus issue / discussion based upon this comment #50607 (comment) and reference the quarkus PR from your issue.