Removes Sec-WebSocket-Origin From Websocket HS #9137
Conversation
Sec-WebSocket-Origin is a Server to Client handshake not a Client to Server handshake header per the websocket RFC specification. This Resolves Issue netty#9134
|
Can one of the admins verify this patch? |
|
@davydotcom can you point me to the relevant RFC section and add a unit-test ? |
|
@davydotcom, @normanmaurer Hi guys. The |
|
Sure replacing it is an option but the header isn’t required typically if there is no alternate origin from the Host. Currently there is no way to set an alternate origin and if a user wishes to bypass the origin with custom headers they aren’t. Assumptions are being made that are not necessary
… On May 9, 2019, at 5:15 AM, Andrey Mizurov ***@***.***> wrote:
@davydotcom, @normanmaurer Hi guys. The Sec-WebSocket-Origin header for old protocol versions (https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-07, https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10). In latest version https://tools.ietf.org/html/rfc6455 instead of Sec-WebSocket-Origin used Origin header. My suggestion is to replace it and not to delete it at all.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@davydotcom I suggest doing this for consistency with previous versions of the protocol (WebSocketClientHandshaker00, 07, 08). Even if you decide not to do this, please fix the documentation |
|
@netty-bot test this please. |
|
@davydotcom please fix the unit tests and let me know once done: |
|
@davydotcom ping.. .also please sign our ICLA: https://netty.io/s/icla |
|
Closing this due no response from original reporter. |
Sec-WebSocket-Origin is a Server to Client handshake not a Client to Server handshake header per the websocket RFC specification.
This removes the header from the specification. This has been changed because some websocket proxy servers are very picky. There exists other areas that need adjusted for example this client should send "Connection: Upgrade" but instead sends "connection: upgrade"... Some Proxy WS Clients are not adhering properly to case insensitivity specifications and require the proper casing for the keys and values being sent.
Fixes Issue #9134