setup.backend.{name} in toml always create backend with overide_host set as the address
Opened this issue · 9 comments
In toml, get below setup, notice that there is no setting field override_host .
[setup]
[setup.backends]
[setup.backends.example]
address = "example.org"
description = "example"
port = 443
After running fastly compute publish
We get a service with a backend that has "override host" set to example.org
Currently, there is no way to set up a backend with an empty "override host"
Have you tried removing the setting in the management console after the fact? In my experience, this makes the backend stop functioning, so setting this value seems necessary.
In many cases, getting override host set is needed for backend like example.org and and httpbin.org.
but in some situations, I need this field to be blank so that my customized backend to receive the host header of the same value as the client's request.
By the way, local_server has a functional override_host field (with or without the setting makes a difference).
[local_server]
[local_server.backends]
[local_server.backends.backend_b]
url = "https://example.org/"
override_host = "example.org"
in some situations, I need this field to be blank so that my customized backend to receive the host header of the same value as the client's request
The platform doesn't allow this, unless your code registers a dynamic backend. The override host field is not the correct place to allow this feature.
in some situations, I need this field to be blank so that my customized backend to receive the host header of the same value as the client's request
The platform doesn't allow this, unless your code registers a dynamic backend. The override host field is not the correct place to allow this feature.
When making a static backend in the UI, this is exactly how it works, the platform allows it, override_host was added as a way to improve this for users because many users wanted to set the host header value in the backend definition rather than in their code. We've since come to a place where we are inconsistent in what we do by default for users. The UI will not add override host by default, but the cli will.
We've since come to a place where we are inconsistent in what we do by default for users. The UI will not add override host by default, but the cli will.
I thought it was the opposite, but I could be mistaken.
The UI will not add override host by default, but the cli will.
Not only cli will (add override host by default), there is no way to let cli to not do it
Indeed, the current data model for setup in fastly.toml doesn't offer any mechanism to set override_host, cert_host, and use_sni even though the local_server block does. This is quite unfortunate as the behavior should be consistent. I'll do some investigating today to see if this can be added relatively quickly, without waiting for the fastly.toml redesign that we've been discussing.
Well, the fix won't be quick as it will require extensive work in the test suite for the deploy command, but it will get done anyway. Look for some progress in a week or two.