add response-outparam.send-informational
#139
Conversation
|
I believe the CI failure is due to a bug in how |
|
The CI failure should be addressed by bytecodealliance/wasm-tools#1958 once that fix makes its way to a |
lukewagner
left a comment
lukewagner
left a comment
There was a problem hiding this comment.
In a 0.3 interface response-outparam goes away and we have to worry more about composability, but for a 0.2 interface, we don't have practical component-to-component composition, so this makes sense.
This allows a server to send zero or more HTTP 1xx responses prior to sending the final response using `response-outparam.set`. Note that this does not include support for consuming informational responses for outbound requests (which would be required to losslessly proxy such requests). Signed-off-by: Joel Dice <[email protected]>
Signed-off-by: Joel Dice <[email protected]>
dicej
force-pushed
the
send-informational
branch
from
7687721 to
a377bea
Compare
Signed-off-by: Joel Dice <[email protected]>
This includes two changes: # WebAssembly/wasi-filesystem#165 Documentation update # WebAssembly/wasi-http#139 Adds a new unstable `send-informational` function to the `response-outparam` resource. I've left this `unimplemented!()`.
| /// Unlike `response-outparam.set`, this does not consume the | ||
| /// `response-outparam`, allowing the guest to send an arbitrary number of | ||
| /// informational responses before sending the final response using | ||
| /// `response-outparam.set`. |
There was a problem hiding this comment.
Maybe a bit late, but does this also allow sending 101 Switching Protocols which indicates that the following data will be for a non-http protocol?
There was a problem hiding this comment.
I haven't tried it myself, but I think that should work even without response-outparam.send-informational. IIUC, a 101 only requires sending a single HTTP-level response (unlike 103, which involves sending more than one), so presumably you could use response-outparam.set to send a 101, then treat the request input-stream and response output-stream as a full-duplex connection over which the agreed-upon protocol may proceed.
Whether that works today with e.g. wasmtime-wasi-http is another question -- probably not, but I don't see any obstacle at the WIT interface level to making it work.
This includes two changes: # WebAssembly/wasi-filesystem#165 Documentation update # WebAssembly/wasi-http#139 Adds a new unstable `send-informational` function to the `response-outparam` resource. I've left this `unimplemented!()`.
* Update to WASI 0.2.6. This includes two changes: # WebAssembly/wasi-filesystem#165 Documentation update # WebAssembly/wasi-http#139 Adds a new unstable `send-informational` function to the `response-outparam` resource. I've left this `unimplemented!()`. * Trap instead of panic
* Update to WASI 0.2.6. This includes two changes: # WebAssembly/wasi-filesystem#165 Documentation update # WebAssembly/wasi-http#139 Adds a new unstable `send-informational` function to the `response-outparam` resource. I've left this `unimplemented!()`. * Trap instead of panic
3 participants
This allows a server to send zero or more HTTP 1xx responses prior to sending the final response using
response-outparam.set.Note that this does not include support for consuming informational responses for outbound requests (which would be required to losslessly proxy such requests).