outgoing-handler and valid request-options #813

Activity

1. acfoltzer commented on Oct 19, 2023

   

   acfoltzer

   on Oct 19, 2023

   Contributor

   More actions

   It also leaves the door open to worlds that can offer additional request options (e.g. enforce TLS, client certificates) the ability to add more setters and getters of the request-options type as standalone functions.

   I'd strongly prefer this option for these extensibility reasons. As it stands, I've been planning to implement some embedder-specific configuration options as standalone functions on outgoing-request.
2. lukewagner commented on Oct 20, 2023

   

   lukewagner

   on Oct 20, 2023

   Last edited by lukewagner

   Member

   More actions

   Great points! I like the idea of making this a resource type with fallible setters that communicate clearly when setting the option will have no effect. To Adam's point, this also provides a nice extensibility point. Concretely, a platform foo can define:

   package foo:http;
   interface additional-request-options {
     use wasi:http/types.{request-options};
     %[method]request-options.foo: func(v: string) -> result
   }

   which an OOP-language bindings generator will then install onto the synthesized class or prototype chain of wasi:http/types.request-options. (On a side note: talking to @elliottt about this extensibility pattern recently, he wondered whether there could be some new WIT syntax added in the future (for "extending" a resource) that desugared into what's shown above so that we're not having to write the explicit [method] names.)
3. ricochet

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

   added

   P-httpProposal: wasi-httpProposal: wasi-http

   on Nov 25, 2025
5. 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