Repository navigation
get_host should allow empty host #3142
Description
#3113 updated get_host to always validate the host characters. However, it also disallowed the empty string. This is a bit too strict, it should only validate the string if it's not empty, or if trusted_hosts is passed. And if it's not valid characters, it should return the empty string rather than failing.
This will match Django's behavior. I thought I had matched it before, as I referred to it when trying to figure out the right behavior here. But I ended up being more strict than it is. It treats empty strings and invalid characters as the empty string, rather than immediately returning an error.
Host is also nonexistant in HTTP/0.9 and optional in HTTP/1.0, so it might appear as the empty string in those cases and should be passed through.
To be clear: domain names still can't contain _ or a bunch of other characters. If you have a domain like that, you need to report it to/fix whatever's generating such a name. It just shouldn't fail loudly immediately, although it might produce invalid results or fail in other ways later.
davidismWerkzeug 3.1.8 is available on PyPI.
The original change caused people to realize that Docker has had multiple issues related to generating domains that are invalid when used as hostnames. docker/cli#3364 docker/compose#229 Ultimately, you either need to use aliases or other Docker features to set up valid hostnames despite it, or Docker needs to stop generating invalid hostnames. Until then, any tools you use could fail at any time if they're expecting valid data where Docker is generating invalid data. Werkzeug is not special in this regard, it just happened to be the thing that caused you to discover this issue.
Activity
Sillocan commentedon Mar 25, 2026
Not to be pedantic, but did you mean "host names still can't container
_"? Domains can technically have underscores as it's valid for DNS to provide_. RFC-2181 has no restrictions other than length. There are domains such as_jabber._tcp.gmail.comwhich are fully valid.I think docker also allows for underscores (which is where my app broke) but that one can be fixed relatively easily.
marcraft2 commentedon Mar 26, 2026
Hi, I’m also hitting this regression in Werkzeug 3.1.7.
After updating, all my HAProxy HTTP health checks started failing with 400 Bad Request because the Host header wasn’t being recognized as trusted. Previously, it worked fine with an empty or simple host string.
In my setup:
HAProxy sends GET /ping HTTP/1.0 without a Host header for some backend checks.
Werkzeug now rejects it, even though HTTP/1.0 allows an empty Host.
This breaks health checks for multiple services without any code changes other than the WerkZeug update.
It would be great if Werkzeug could either:
Treat empty Host headers as valid for HTTP/1.0 (like Django does), or
Allow configuring “trusted empty hosts” to avoid breaking existing setups.
This feels like a backwards-incompatible change that impacts operational setups like HAProxy health checks.
Thanks for looking into this!
paraboul commentedon Mar 30, 2026
Hey,
This also broke for us in a Docker Swarm setup (and docker compose in dev). It's a fairly common use case to use a service name as a host (which can include underscores) and actually the recommended way on a docker network.
davidism commentedon Apr 1, 2026
Looked at Django some more, and apparently it doesn't pass through invalid values, I re-misread the code. It doesn't have an equivalent of Werkzeug's host routing, so it doesn't check the host for each request, only when a specific view accesses it, at which point it would fail just like Werkzeug, since the host is missing or invalid.
davidism commentedon Apr 2, 2026
Werkzeug 3.1.8 is available on PyPI.
The original change caused people to realize that Docker has had multiple issues related to generating domains that are invalid when used as hostnames. docker/cli#3364 docker/compose#229 Ultimately, you either need to use aliases or other Docker features to set up valid hostnames despite it, or Docker needs to stop generating invalid hostnames. Until then, any tools you use could fail at any time if they're expecting valid data where Docker is generating invalid data. Werkzeug is not special in this regard, it just happened to be the thing that caused you to discover this issue.