Repository navigation
[v0.3] Why bother with request-options when asyncs are there? #790
Description
What's the point of adding ad-hoc timeouts to requests via request-options? It seems entirely sufficient and possibly more efficient to place an async bound on a larger unit of computation, for example on connecting to a remote system, or on fully writing the request with headers, or on the same with body and trailers.
I get the need for a server to manage scarce resources in the face of incoming connections, and something like some of these timers may be useful there; but request-options is for making a request, not for handling a request.
Consider removing request-options. Or, documenting what it's for, in the README.md maybe :)
Activity
pchickey commentedon Aug 29, 2025
It may be possible to use new async functionality in p3 to make new futures that resolve when the client has connected and received first byte, and between bytes should already be taken care of by the body streams.
The other reason request-options exists, and the reason it is structured as a resource instead of a record, is to permit future extensions: embedding can offer a superset of the wasi-http world which has additional import methods on the request-options resource for these non-standard extensions, and the wasi-http interfaces can be extended with additional methods in patch releases as well. These can be used, for example, to configure client TLS, or other extensions like Consider extending the proxy world with an origin could just be a boolean setting in the request-options. So, even if we replace all of the existing request-options methods with futures, I believe we should still retain an optional request-options resource, even if it is a resource that offers just a constructor and no other methods.
Related: #796
lann commentedon Sep 2, 2025
Also notably those timeouts will (typically) be pushed down into the OS network stack which means they don't have to be tracked as separate pollable timers and aren't subject to async scheduling noise. I don't know how important those things are but it is a difference.
lann commentedon Sep 11, 2026
I'm going to close this out because two of the three timeout options would seem to have value beyond what "normal" async timeout can provide. I do however agree that
first-byte-timeoutshould be dropped: #962