Stream: git-wasmtime

Topic: wasmtime / issue #8747 Wasmtime sets multiple `Host` head...

Wasmtime GitHub notifications bot (Jun 05 2024 at 11:56):

karthik2804 opened issue #8747:

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](https://github.com/bytecodealliance/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?

Wasmtime GitHub notifications bot (Jun 05 2024 at 12:13):

rylev commented on issue #8747:

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.

Wasmtime GitHub notifications bot (Jun 05 2024 at 14:27):

alexcrichton edited issue #8747:

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?

Wasmtime GitHub notifications bot (Jun 05 2024 at 14:33):

alexcrichton commented on issue #8747:

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 https://github.com/bytecodealliance/wasmtime/pull/8563 (which required a follow-up fix at https://github.com/bytecodealliance/wasmtime/pull/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?

Wasmtime GitHub notifications bot (Jun 05 2024 at 14:33):

alexcrichton commented on issue #8747:

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

Wasmtime GitHub notifications bot (Jun 05 2024 at 14:39):

karthik2804 commented on issue #8747:

We were testing with version 18.0.4.

Wasmtime GitHub notifications bot (Jun 05 2024 at 14:50):

alexcrichton commented on issue #8747:

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

Wasmtime GitHub notifications bot (Jun 17 2024 at 11:51):

karthik2804 commented on issue #8747:

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

Wasmtime GitHub notifications bot (Jun 17 2024 at 16:38):

alexcrichton closed issue #8747:

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?

Last updated: Oct 23 2024 at 20:03 UTC