Explicit run-server needed?

[brendandburns]

While there is a method for handling web requests, there's no explicit method for starting a web server.

I don't know if we want to make this part of the interface, or we want to assume that there is a configured server that wraps this WASI module, but it seemed worth mentioning/asking.

cc @lukewagner

[lukewagner]

Definitely a good question to ask. As is, the wasi:http/proxy world design assumes that the starting of the server is in the host. This matches the original proxy-wasm proposal from which this proposal is derived and is an important characteristic for many of the intended embeddings of the wasi:http/proxy world. I can write up a PR to mention this as a high-level design choice in README.md.

[brendandburns]

I guess the question that I have is how do I activate the HTTP client side of the world without also activating the HTTP serving side of the world?

I could definitely do that in the host with a flag, but it feels a little weird that you could load a module that expects to be called to serve HTTP requests, but the host doesn't enable it, it feels like that should explicitly fail, rather than silently not work, but I'm not certain.

[brendandburns]

Should there at least be a method in the world that is something like wants_http_serving() or something like that?

[lukewagner]

Ah, great question. I think a good way to express that is to define a distinct world that exports the interface that the guest code does expect to be called through. E.g., the wasi-cli proposal could define a world:

default world http-client {
  import default-outgoing-HTTP: http.outgoing-handler
  export cli.main
}

(assuming we factor out the cli.main interface from the command world). Guest code targeting this world would then only export the main interface instead of the outgoing-handler interface. A host could support one or the other worlds but could also support both worlds by reflecting on the deployed component to see whether the main or incoming-handler interface was exported (inspecting the id subfield of the export names).

[autodidaddict]

While there is a method for handling web requests, there's no explicit method for starting a web server.

I don't know if we want to make this part of the interface, or we want to assume that there is a configured server that wraps this WASI module, but it seemed worth mentioning/asking.

cc @lukewagner

My 2 🪙:

I typically view components as pieces that sit inside hosts, and I feel like the act of starting a server is the responsibility of the host in which a component resides. The host knows what port number to use, what CORS settings to have, what TLS termination there should be, etc.. these details are ones that I typically try and keep out of a wasm module. If a component can start its own server, it now has to be responsible for all of that configuration and networking baggage that we want the host to handle for us.

It also makes it harder for an HTTP request handler to work in both serverless and microservice style deployments, where the former might be multiplexing or proxying requests in a way opaque to the component.

In other words, in my ideal world, a component is concerned with what is inside the request and what to respond with, but not with how that request arrived or how the response will be delivered.