Explicit run-server needed? #819

Activity

1. lukewagner commented on Mar 27, 2023

   

   lukewagner

   on Mar 27, 2023

   Member

   More actions

   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.
2. brendandburns commented on Mar 29, 2023

   

   brendandburns

   on Mar 29, 2023

   ContributorAuthor

   More actions

   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.
3. brendandburns commented on Mar 29, 2023

   

   brendandburns

   on Mar 29, 2023

   ContributorAuthor

   More actions

   Should there at least be a method in the world that is something like wants_http_serving() or something like that?
4. lukewagner commented on Mar 29, 2023

   

   lukewagner

   on Mar 29, 2023

   Member

   More actions

   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).
5. autodidaddict commented on May 16, 2023

   

   autodidaddict

   on May 16, 2023

   More actions

   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.
6. ricochet

   transferred this issue fromWebAssembly/wasi-httpon Nov 25, 2025
7. ricochet

   added

   P-httpProposal: wasi-httpProposal: wasi-http

   on Nov 25, 2025
8. ricochet

   added

   S-inactiveStatus: no discussion in over a year. Records silence during triage; not a proposal to close.Status: no discussion in over a year. Records silence during triage; not a proposal to close.

   on Aug 20, 2026