websocket: switch back to the gorilla library #2280
Conversation
| n, err := c.Conn.Read(b) | ||
| if err == nil && n == 0 && c.readAttempts < maxReadAttempts { | ||
| c.readAttempts++ | ||
| // Nothing happened, let's read again. We reached the end of the frame |
There was a problem hiding this comment.
Just flagging that we're losing this comment, but keeping this behavior. Maybe a similar comment would be helpful?
There was a problem hiding this comment.
Are we? This was introduced as part of #1982, wasn't it?
|
Sorry you had a bad experience with my library. My delay in dealing with issues was unfortunate and I do sincerely apologize. I just wanted to let you know that all the issues you cited are now fixed for v1.8.8 which will be released tomorrow at noon. nhooyr/websocket#256 Your feedback was very much appreciated even if I was too late to get things in for you. |
|
@nhooyr I see you handled:
Thx that is great, however my opinion is still the same, while gorilla is working (no bug or security issue known) I don't think go-libp2p should try switching away from it. However I'm not a maintainer on go-libp2p. |
|
By all means. I would suggest the same. The WebSocket protocol is stable and so gorilla is fine now and will be fine for a long time. I just wanted to note that the issues cited are now fixed. |
|
I like the WebAssembly support in @nhooyr library, among other things. It would be worthwhile to have a look at including it, imo |
Turns out that @Jorropo was right in #1982 (comment). Switching to nyhoor's websocket library has caused us nothing but pain (examples: #1982, #2201, and most recently, ugly workaround in the gating tests).
Although the author claims to fix critical issues, nothing is happening when actual issues are reported (examples: nhooyr/websocket#367, nhooyr/websocket#355 and nhooyr/websocket#384), and there hasn't even been a patch release April 2021).
This PR reverts the changes made to the WebSocket transport in reverse order they were made:
After that, it reapplies the one fix that was unrelated to the library used: #2199.