-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handler Stream Dispose Fix #9
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer to keep the HTTP and WS fixes in separate PRs, especially given you're not sure the WS fix is even necessary and that part of the code is extremely rough and unfiinished
Hydra/WrapperStream.cs
Outdated
|
||
protected WrapperStream(Stream stream) | ||
protected WrapperStream(Stream stream, bool ownStream = false) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer if this was not a default parameter, since there's no real reason one should be the default over the other in which case the behaviour should probably always be specified by the caller.
Hydra/SizedStream.cs
Outdated
@@ -20,7 +20,7 @@ internal class SizedStream : WrapperStream | |||
/// </summary> | |||
/// <param name="stream">Stream to wrap</param> | |||
/// <param name="length">Length to limit to</param> | |||
internal SizedStream(Stream stream, int length) : base(stream) | |||
internal SizedStream(Stream stream, int length, bool ownStream = false) : base(stream, ownStream) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same thing here
Done. However the WebSocket changes are needed in this PR unless you're fine with compile errors |
Previously handlers for HTTP Requests such as BMBF's web server could dispose the NetworkStream used to communicate to the client when say using a ZipStream.
It seems undesirable to have handlers abruptly close the stream used to communicate to the client, even intentionally. Without this, any result error or otherwise would never reach the client and the server would spam exceptions.
This has already been fixed in BMBF 2 by leaving the ZipStream stream open in MR !13.
I applied similar changes to the web socket though those are more questionable and probably redundant.