lann
commented
3 days ago I suppose the obvious alternative here would be protocol-specific interfaces e.g. wasi-websocket, which would be implementable in browsers unlike a generic upgrade mechanism.
Both could also be supported, e.g. a wasi-websocket connection resource that can be obtained either by an upgrade interface that takes ownership of a wasi-http request/response or via a constrained browser-compatible outbound-websocket interface.
The HTTP "Upgrade" mechanism allows for a client and server to negotiate switching an HTTP connection to use another protocol. This is most notably used by WebSockets but has a few other uses including the popular WebTransport proposal.
I would expect implementation of this feature to be optional, so it might make sense for it to use separate interface(s) that can take ownership of a request/response and return some stream(-like) resource representing the underlying connection. This could even perhaps live outside of wasi-http itself if we find a good pattern for representing this kind of "interface extension", similar to proposals in #4.