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 memoryview_to_bytes
.
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