This is primarily useful in testing or private networking scenarios where the client wants to nominally connect to a host but use a different address than DNS would resolve, e.g.:
- An override is configured for
api.example.com -> test-api.example.com
- Guest makes a request to
https://api.example.com
- TCP connection is established to
test-api.example.com
- TLS establishment uses
api.example.com as the server name
- HTTP
Host header is api.example.com
This effect is sometimes achieved instead by overriding the HTTP Host header, but this will typically cause server certificate validation to fail which then requires separate TLS config changes (often just e.g. --insecure).
I see two (not necessarily exclusive) approaches:
Override in runtime config
Something like:
[outbound_networking.hosts."api.example.com"]
override_resolution = "test-api.example.com"
This would be relatively straightforward to implement and would cover many use cases but might not work well where more dynamic configuration is needed.
Override in the guest
I think the most "component-y" way to implement this would be with a new WIT interface(s) that would be sort of "extension(s)" to WASI:
package spin:wasi-extensions;
interface http-extensions {
use wasi:http/types@0.3.0-rc-2026-03-15.{request};
set-connect-host(request: borrow<request>, connect-host: string) -> result<_, some-error>;
}The connect-host would need to be covered by an allowed_outbound_hosts entry or some new manifest (allowed_host_overrides?) and/or runtime config allowlist mechanism.
This is primarily useful in testing or private networking scenarios where the client wants to nominally connect to a host but use a different address than DNS would resolve, e.g.:
api.example.com->test-api.example.comhttps://api.example.comtest-api.example.comapi.example.comas the server nameHostheader isapi.example.comThis effect is sometimes achieved instead by overriding the HTTP
Hostheader, but this will typically cause server certificate validation to fail which then requires separate TLS config changes (often just e.g.--insecure).I see two (not necessarily exclusive) approaches:
Override in runtime config
Something like:
This would be relatively straightforward to implement and would cover many use cases but might not work well where more dynamic configuration is needed.
Override in the guest
I think the most "component-y" way to implement this would be with a new WIT interface(s) that would be sort of "extension(s)" to WASI:
The
connect-hostwould need to be covered by anallowed_outbound_hostsentry or some new manifest (allowed_host_overrides?) and/or runtime config allowlist mechanism.