How should redirects interact with `allowed_http_hosts`?

[itowlson]

At the moment, Spin's outbound HTTP interface automatically follows redirects. This happens within the reqwest stack in the Spin host, and therefore bypasses allowed_http_hosts.

Generally, this is reasonable, because it means a component granted access to, say, twitter.com does not need to be reconfigured when that domain starts redirecting to x.com. However, there may be cases where it is not safe to follow the redirection: consider the case where the operator of a Spin hosting environment (e.g. a Kubernetes cluster) wants to prevent redirection to internal services.

To complicate matters, our understanding of wasi-http is that the host should not automatically follow redirects; it would be up to a higher-level HTTP stack running inside the guest to manage redirect policy. In that case, the host cannot know that the request to the non-allowed x.com is merely following a redirect from the allowed twitter.com - it must enforce allowed_http_hosts on all requests. Which could be vexing for an application which just wants to get the latest cat GIFs and not have to constantly chase the hostname du jour.

(As a side note, Cloud does not currently automatically follow redirects. So it avoids the 'policy bypass' problem but runs into the 'chase the hostname' problem.)

[vdice]

Assuming support for following redirects is present in the backend implementations (eg wasi-http/spin locally and Cloud), would this be an opportunity to add another piece of component config eg allow_http_redirects: {true|false} with the default being false? However, it sounds like work is needed in both cases (wasi-http, Cloud) to even support this, so perhaps coming up with a config solution is premature.