-
Notifications
You must be signed in to change notification settings - Fork 25
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
Make the close reason available to application code #29
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.
If I understand correctly the design of this crate, I think this PR has a fundamental problem: the Error::Closed
enum as it currently is represents a way to signal to the user that a close frame has been sent/received in the past, and not as a way to signal instantaneously that a close frame has been received.
To me, there should instead of a new variant added to Incoming
to contain the close reason. As mentioned, Error::Closed
means "you can't do that because the connection is already closed".
code: u16, | ||
descr: Option<String>, |
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 suppose you want to access these fields
code: u16, | |
descr: Option<String>, | |
pub code: u16, | |
pub descr: Option<String>, |
Co-authored-by: Pierre Krieger <[email protected]>
Closing in favour of #31 |
When a remote sends us a
CLOSE
message it may contain a reason code and "application data" with further details about why the connection was closed.Before this PR there was no way for applications using
soketto
to know what the code/data was sent from the remote.Further context here.