Handle 1xx status codes better by not closing the connection #32
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Both the 100 and 101 status codes require that the connection to the server remain open. The 100 status code is used to tell the client that the server is still receiving its request, and will continue to read request input on the connection. The 101 status code is used to upgrade the existing connection to another protocol, and specifically is NOT used to upgrade a separate connection. Therefore, the connection must remain open after this response in order to facilitate that. RDoc and tests updates included. Signed-off-by: Tim Shadel <github@timshadel.com>
|
Awesome! Pulled! Thanks Tim. |
This pull request was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The 100 and 101 status codes need the connection to remain open in order to comply with their descriptions in the spec. See sections 10.1 and section 8.2.3. There may be other places in the spec that support this idea as well.
Thanks! :-)