Extract WebSocket#do_ping, #do_close helper methods for overrides#15545
Conversation
Before this change, when using `#on_ping` callback and defining your own block of code to handle it, resulted in two `pong` frames being sent to the other site of the WebSocket. This change setups a default ping <-> pong response cycle but once you override it, it will use yours instead.
luislavena
changed the title
|
This has been reported in #8435, but this PR only deals with |
|
|
|
These are WebSocket protocol details that applications shouldn't bother with: the handlers allow you to do something on the application side. I don't think there is anything to fix but the documentation. |
|
Oh, I missed the WebSocket proxy that forwards the ping and pong to the other side, expecting each side to talk to each other. I guess it's an acceptable claim. Edgy, though. |
|
Yeah @ysbaddaden, this proxy thing is a bit tricky for a standard library (aka: general) usage. I might override 🤔 |
|
Perhaps we could extract the implicit ping and pong behaviour into helper methods? |
Per RFC 6455, for any PING frame, a similar PONG frame with same payload is expected as response. Previous change broke that if the developer used `#on_ping` callback to setup their own event, resulting a broken implementation. This extracts both ping and close events as private helpers to ease reutilization/override.
|
Hello folks, thank you for your patience. I decided go with @straight-shoota recommendation and extracted ping and close elements as Thank you again for your time. |
This is no longer relevant and avoids breaking RFC 6455
straight-shoota
changed the title
WebSocket#do_ping, #do_close helper methods for overrides
6 participants
Before this change, when using
#on_pingcallback and defining your own block of code to handle it, resulted in twopongframes being sent to the other site of the WebSocket.This change setups a default ping <-> pong response cycle but once you override it, it will use yours instead.
Thank you
❤️ ❤️ ❤️