Feature/context takeover #5
Open
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
…essContextTakeover
Feature/impl compress context takeover
mod: split dict to rx and tx
add: context-takeover option to client
mod: remove mutex.
mod: add dict process
Feature/add test
Feature/upgrade writer
Using empty struct for signaling is more idiomatic compared to booleans because users might wonder what happens on false or true. Empty struct removes this problem. There is also a side benefit of occupying less memory but it should be negligible in this case.
…ion: upgrade (gorilla#604) The values of the `Upgrade` and `Connection` response headers can contain multiple tokens, for example Connection: upgrade, keep-alive The WebSocket RFC describes the checking of these as follows: 2. If the response lacks an |Upgrade| header field or the |Upgrade| header field contains a value that is not an ASCII case- insensitive match for the value "websocket", the client MUST _Fail the WebSocket Connection_. 3. If the response lacks a |Connection| header field or the |Connection| header field doesn't contain a token that is an ASCII case-insensitive match for the value "Upgrade", the client MUST _Fail the WebSocket Connection_. It is careful to note "contains a value", "contains a token". Previously, the client would reject with "bad handshake" if the header doesn't contain exactly the value it looks for. Change the checks to use `tokenListContainsValue` instead, which is incidentally what the server is already doing for similar checks.
* Document allowed concurrency on Dialer. * Document allowed concurrency on Upgrader.
Continued work on gorilla#730.
* do not use cached PreparedMessage in broadcast benchmarks * pick better name for benchmark method
- Update instructions to use docker. - Cleanup config file.
To aid protocol error debugging, report all errors found in the first two bytes of a message header.
- Note that a new maintainer is needed. - Remove comparison with x/net/websocket. There's no need to describe the issues with that package now that the package's documentation points people here and elsewhere.
Fixes issue: gorilla#745 With the previous interface, NetDial and NetDialContext were used for both TLS and non-TLS TCP connections, and afterwards TLSClientConfig was used to do the TLS handshake. While this API works for most cases, it prevents from using more advance authentication methods during the TLS handshake, as this is out of the control of the user. This commits introduces another a new dial method, NetDialTLSContext, which is used when dialing for TLS/TCP. The code then assumes that the handshake is done there and TLSClientConfig is not used. This API change is fully backwards compatible and it better aligns with net/http.Transport API, which has these two dial flavors. See: https://pkg.go.dev/net/http#Transport Signed-off-by: Lluis Campos <[email protected]>
* add Sec-WebSocket-Key header verification * add testcase to Sec-WebSocket-Key header verification
…s names with Go 1.18 standard library (gorilla#773)
…lla#788) * return an error when Dialer.TLSClientConfig.NextProtos contains a protocol that is not http/1.1 * include the likely cause of the error in the error message * check for nil-ness of Dialer.TLSClientConfig before attempting to run the check * addressing the review * move the NextProtos test into a separate file so that it can be run conditionally on go versions >= 1.14 * moving the new error check into existing http response error block to reduce the possibility of false positives * wrapping the error in %w * using %v instead of %w for compatibility with older versions of go * Revert "using %v instead of %w for compatibility with older versions of go" This reverts commit d34dd94. * move the unit test back into the existing test code since golang build constraint is no longer necessary Co-authored-by: Chan Kang <chankang@[email protected]>
Signed-off-by: Ye Sijun <[email protected]>
Signed-off-by: Corey Daley <[email protected]>
Update README.md
…tp default buffers (gorilla#761) **Summary of Changes** 1. Add an example that uses the write buffer pool The loop process of the websocket connection is inner the http handler at existing examples， This usage will cause the 8k buffer(4k read buffer + 4k write buffer) allocated by net.http can't be GC(Observed by heap profiling, see picture below) . The purpose of saving memory is not achieved even if the WriteBufferPool is used. In example bufferpool, server process websocket connection in a new goroutine, and the goroutine created by the net.http will exit, then the 8k buffer will be GC.  Co-authored-by: hakunaliu <[email protected]> Co-authored-by: Corey Daley <[email protected]>
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.
No description provided.