Presently if you open up a stream that is a "permanent" streamed reply, there is no way to unsubscribe from the connection. Ordinarily, over http2 this would involve sending a RST_STREAM frame on the with the stream id that is being cancelled. This seems only particularly relevant for streaming responses from the server as both the bidi and client streams have the ability for the client to terminate the stream from a higher level means. Since the current implementation of streamed responses is currently synchronous, we can't include a cancellation action in the return type. However I believe it is possible through a series of masks/unmasks to use asynchronous exceptions to only be delivered inside the scope where the stream id is available, allowing us to use the stream id to create the RST_STREAM frame.
Thoughts @lucasdicioccio?
Presently if you open up a stream that is a "permanent" streamed reply, there is no way to unsubscribe from the connection. Ordinarily, over http2 this would involve sending a RST_STREAM frame on the with the stream id that is being cancelled. This seems only particularly relevant for streaming responses from the server as both the bidi and client streams have the ability for the client to terminate the stream from a higher level means. Since the current implementation of streamed responses is currently synchronous, we can't include a cancellation action in the return type. However I believe it is possible through a series of masks/unmasks to use asynchronous exceptions to only be delivered inside the scope where the stream id is available, allowing us to use the stream id to create the RST_STREAM frame.
Thoughts @lucasdicioccio?