Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/xpra/net/protocol.py", line 734, in _read_parse_thread_loop self.do_read_parse_thread_loop() File "/usr/lib/python2.7/dist-packages/xpra/net/protocol.py", line 767, in do_read_parse_thread_loop read_buffer = read_buffer + buf TypeError: unsupported operand type(s) for +: 'memoryview' and 'memoryview'
This bug only happens when I go through reverse proxy (traefik in kubernetes) to access the xpra websocket service.
I have a patch for that in the 2.4.x branch:
diff --git a/tags/v2.4.x/src/xpra/net/protocol.py b/tags/v2.4.x/src/xpra/net/protocol.py index 1c4f90bda..92459108d 100644 --- a/tags/v2.4.x/src/xpra/net/protocol.py +++ b/tags/v2.4.x/src/xpra/net/protocol.py @@ -764,7 +764,7 @@ class Protocol(object): self.idle_add(self.close) return if read_buffer: - read_buffer = read_buffer + buf + read_buffer = memoryview_to_bytes(read_buffer) + memoryview_to_bytes(buf) else: read_buffer = buf bl = len(read_buffer
This part has heavily changed in trunk, and I have not tested if this bug happens on trunk as well.
patch for trunk
Following the changes in #2121, I don't think that trunk needs the patch above: my guess is that your proxy must be slicing the websocket data using continuation frames, we already handle those by calling
memoryview_to_bytes since r21542.
But please test to confirm as I do not have a proxy to use for testing, otherwise 2.5 will be released soon with this bug.
As for v2.4 (soon to be abandoned), I have applied a different fix in r21784 so as not to penalize the other transport protocol backends with the extra call to
Unfortunately, it is still going to make things slower for all websocket users (despite the fact that very few users may be hitting this issue..). That's one of the reasons why #2121 was needed.
Please close if that works for you.
fixed in latest 2.5 beta
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2160