Wasmtime sets multiple Host header on wasi-http when guest specifies it.

[karthik2804]

It appears that wasmtime's implementation of outbound calls using wasi-http unconditionally set the Host header here. It then appears to iterate over the headers provided by the guest here leading to there being multiple host headers when the guest automatically sets a host header which is the case for apps built using StarlingMonkey.

This leads to certain servers rejecting the request because of duplicate headers. Should the guest not be setting a header or should wasmtime only set it conditionally?

[rylev]

One additional piece of context is that it seems that StarlingMonkey is setting the HOST header to the host without the port while wasi-http sets it to the host and port. If doing de-duplication of the HOST header, we should treat hosts without parts as equal to hosts with ports if the port matches the default port for the scheme.

[alexcrichton]

Wasmtime in theory should be stripping the host header via functionality like this. The issue of setting the host and port should be fixed through #8563 (which required a follow-up fix at #8671, but both should be in the 21.0.0 release).

Auditing a bit it looks like any guest-specified header goes through filtering before being inserted into req.headers, so now I'm also a bit confused how a second one could show up there.

Do you have an example guest which runs afoul of the double-host header?

[alexcrichton]

(and/or were y'all testing with 21.0.0? or an older version?)

[karthik2804]

We were testing with version 18.0.4.

[alexcrichton]

Aha ok makes sense! The Host header was made "forbidden" in #7905 which was first landed in 19.0.x so I think this might be fixed with a wasmtime upgrade?

[karthik2804]

I can confirm that this issue has been fixed by upgrading to wasmtime 21.