Add headers in wasmtime serve via CLI

[rajsite]

Feature

I'd like the ability to specify / override headers that are passed through requests when using wasmtime serve. Handy for specifying cookies, api keys, etc expected to be in each request to the wasm component being served.

Benefit

Make it easier to simulate authenticated sessions / being behind a proxy or gateway that adds expected headers from cli when testing.

Implementation

Following the curl -H cli would be nice.

(just reproducing from the curl docs):

wasmtime serve -H "X-First-Name: Joe" main.wasm
wasmtime serve -H "User-Agent: yes-please/2000" main.wasm
wasmtime serve -H "Host:" main.wasm
wasmtime serve -H @headers.txt main.wasm

Alternatives

Been setting up a small proxy in node to simulate that and it's pretty cumbersome.

[alexcrichton]

Thanks for the report! This seems like a reasonable feature request to me. Do you know if there's prior art in other "serve this thing" style utilities? I realize curl has good precedent here but that's more of "I'm sending a thing and starting from nothing" whereas wasmtime serve is "I'm receiving a thing that already has headers" so there's questions like what to do if the header is already there which aren't present in the curl case.

In the meantime env vars would probably suffice for configuring this, but if there's good precedent I think it'd make sense to add this too.

[rajsite]

wasmtime serve is "I'm receiving a thing that already has headers"

I guess from that perspective wasmtime is acting more like a proxy. The things that come to mind in that space to me are apache mod_headers and nginx add_header. On the application side features like Angular's dev server bypass proxy, or webpack's equivalent devServer.proxy. Ranging from decently complex configuration systems to arbitrarily complex evaluating a script.

there's questions like what to do if the header is already there which aren't present in the curl case.

curl has a concept of clearing internally set headers from the referenced docs and reproduced as follows:

Note that if you should add a custom header that has the same name as one of the internal ones curl would use, your externally set header is used instead of the internal one.

Framing from curl's api if we use the mental model that all the headers are internal then it would be replacements but if all the headers were "normal" then the behavior of the CLI is to send combined field values.

I think the behavior I'd expect is a mix, i.e. assuming an incoming Header of Hello: World something like wasmtime serve -H "Hello: Earth" would replace any existing Hello header and wasmtime serve -H "Hello: Earth" -H "Hello: Mars" would replace the incoming World with the combined fields value of Earth and Mars.

In the meantime env vars would probably suffice for configuring this

Have thoughts on what those env vars would look like? (I'm not familiar with wasmtime's env var conventions)

[alexcrichton]

That all sounds reasonable to me, thanks for the background!

For env vars it'd involve passing, for example -Sinherit-env and then using normal env-var-accessing-things in the guest language.

[rajsite]

For env vars it'd involve passing, for example -Sinherit-env and then using normal env-var-accessing-things in the guest language.

Oh I see. I misunderstood and thought you were suggesting ENV vars as an alternative API to cli options for configuring a header to add if we weren't convinced on the CLI api proposed in the PR description yet, i.e. something like WASMTIME_SERVE_REPLACE_HEADERS="Hello: World" (not clear how to specify multiple headers, maybe JSON encode an array instead).

The intention was to better represent the runtime environment of some wasm components where the component author would expect certain headers to exist on incoming requests. Trying to avoid putting that complexity on each wasm component author that they should handle both env configuration (dev workflow) and header configuration (production workflow) differently for those values.

The workaround I'm doing now that preserves the production behavior in their dev workflow using wasmtime serve is setting up a proxy in front of wasmtime serve to add the headers to incoming requests.

Another potential workaround I could think of would be wac-ing on a component to inject the headers (seems like the class of configuration that could be useful in wasi-virt too).

[alexcrichton]

Oh sorry yeah the env var idea was just there as a workaround for not having this, agreed that this is well-motivated enough that it's reasonable to add any time!