outgoing-handler and valid request-options

[pchickey]

Presently, we have a record request-options full of optional timeout values, which is accepted as a parameter by outgoing-handler.handle. The three timeouts are for making the connection, first byte, and between bytes.

Some implementations, such as one implemented using Web fetch, will be not able to implement these timeouts faithfully. Should we specify that, if the options cannot be satisfied, these handlers return an error from handle? If so, we need an error variant, or some different error enum, that will report this properly.

One alternative in this design space is to make request-options a resource declared in the outgoing-handler interface. It can have a constructor taking no arguments named default, and for each timeout currently in the record, make a getter method that returns option, and a setter method that takes option and returns result. This allows the interface to deny an individual field. 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.

[acfoltzer]

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.

[lukewagner]

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.)