rsv is not implemented, yet

[jakobdo]

Anyway to get this implemented ? 👍

[gkivanov]

+1

[pmp-p]

+2

[Vacant0mens]

+1

[asafmod]

This is caused probably by kernel tcp buffers being overrun.

[jeffro256]

+1

[lickmydesign]

+1

[crazbot]

+1

[myxtype]

+1

[fspaniol]

+1

[skakim]

+1

[LobbyBoy-Dray]

+1, so how to solve it?

[liris]

I don’t understand what you want.

[pmp-p]

@liris extended payload length ( Payload length: 7 bits, 7+16 bits, or 7+64 bits
) are not implemented in a bidirectionnal way. you can send big packet but only receive 125B max at once.

[thehackercat]

+1

[ly95]

+1

[skakim]

@liris The problem is the exception raised in this line. This Issue is about multiple people needing this to be implemented for their projects.

[Couperin100]

What resolved it for me was that my client header contained:
Sec-WebSocket-Extensions: permessage-deflate
so by removing it, I didnt see the error anymore.

[HarishB167]

What resolved it for me was that my client header contained:
Sec-WebSocket-Extensions: permessage-deflate
so by removing it, I didnt see the error anymore.

Thank yours solution worked. It should be in top results of google search.

[Couperin100]

Maybe this issue should be implemented in a way to handle rsv(s) not being set to 0 where different websocket extension negotiations are handled correctly else rsv should always be set to 0 according to the documentation highlighted with the code:

websocket-client/websocket/_abnf.py

Line 109 in df275d3

and http://tools.ietf.org/html/rfc6455#section-5.2

.

https://tools.ietf.org/html/rfc6455#section-5.2

RSV1, RSV2, RSV3: 1 bit each

  MUST be 0 unless an extension is negotiated that defines meanings
  for non-zero values.  If a nonzero value is received and none of
  the negotiated extensions defines the meaning of such a nonzero
  value, the receiving endpoint MUST _Fail the WebSocket
  Connection_.

[engn33r]

Hi everyone, can someone clarify the exact use case that you are looking for rsv support for? Are you using WebSocket Compression with the header Sec-WebSocket-Extensions: permessage-deflate from RFC 7692, or is there another use for the rsv values that I am overlooking? The project FAQ mentions that WebSocket Compression is not supported, and I don't plan on implementing it myself in the coming months - a PR would certainly be welcome.

[pmp-p]

I don't plan on implementing it

but then it would not be websocket

is there another use for the rsv values that I am overlooking

https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10#section-4.2

As i said extended payload must work both way and at the time it was not working, but as rsv is only a part of the opcode maybe the exception message was just misleading
. Next time don't let issue hanging if you want relevant information. from my point of view websocket-client is forever broken, and i did not try to use it since.

[engn33r]

Unless I am mistaken, the rsv bit it only used for WebSocket extensions. If I am mistaken, please let me know and we can discuss other edge cases. At the current time, this library does not support any extensions, and therefore expects rsv = 0, otherwise the exception will be triggered (which everyone in this thread has probably seen). I understand it would be ideal to support extensions, but I personally don't have the time to implement this functionality right now. Maybe I will implement this in the distant future, but if you really want this functionality added to in this library and do not want to switch to another library that has such support, it would be great if you could help by contributing a PR. While you may not like this answer, I will acknowledge this issue exists but will close as won't fix. I have updated the README and the FAQ to reflect this.

As one earlier solution pointed out, if you are able to create a WebSocket connection without the Sec-WebSocket-Extensions: header, then you should not encounter this issue.

Edit: It looks like PR #576 may have added some support for viewing compressed text in the wsdump.py script. If someone wants to weigh in on whether they have used this script with existing partial support for permessage-deflate, that would be helpful. The autobahn results indicate zero support with the underlying library.

[adrianbosacki1]

Thank you, you made my day.