xpra icon
Bug tracker and wiki

Opened 3 months ago

Closed 3 weeks ago

#2316 closed defect (worksforme)

Trackbacks on bytestreams.py when HTML5 Client tries to reconnect

Reported by: zaveri Owned by: Antoine Martin
Priority: critical Milestone: 3.0
Component: html5 Version: trunk
Keywords: Cc:

Description

Happens regularly on Initial Connection with an HTML 5 Client. Once connected happens occasionally on launching of a new application, reconnection of session or disconnect

version - xpra v3.0-r22786


2019-06-04 12:04:05,994 untilConcludes(<bound method SocketConnection.is_active of tcp socket: 10.0.3.42:12000 <- 10.0.4.36:49783>, <bound method SocketConnection.can_retry of tcp socket: 10.0.3.42:12000 <- 10.0.4.36:49783>, <built-in method recv of _socket.socket object at 0x7f889fbdbc00>, (65536,), {}) timed out, retry=socket.timeout
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xpra/net/bytestreams.py", line 116, in untilConcludes
    return f(*a, **kw)
timeout: timed out

Attachments (1)

2316-info.txt (159.8 KB) - added by zaveri 2 months ago.

Download all attachments as: .zip

Change History (12)

comment:1 Changed 3 months ago by Antoine Martin

Resolution: fixed
Status: newclosed

I think those are likely to be caused by #2315.

Feel free to re-open if you can reproduce with r22852 or later.

comment:2 Changed 2 months ago by zaveri

Resolution: fixed
Status: closedreopened

I am still seeing this on initial connection with xpra v3.0-r22875

2019-06-11 15:16:49,777 New tcp connection received from 10.0.4.71:59728 on 0.0.0.0:15000
2019-06-11 15:16:49,777 make_protocol(tcp, tcp socket: 10.0.3.198:15000 <- 10.0.4.71:59728, <function ServerCore.make_protocol.<locals>.xpra_protocol_class at 0x7f6fbe260f28>)
2019-06-11 15:16:49,777 io_thread_loop(read, <bound method Protocol._read of Protocol(tcp socket: 10.0.3.198:15000 <- 10.0.4.71:59728)>) loop starting
2019-06-11 15:16:49,878 untilConcludes(<bound method Connection.is_active of tcp socket: 10.0.3.198:15000 <- 10.0.4.71:59728>, <bound method Connection.can_retry of tcp socket: 10.0.3.198:15000 <- 10.0.4.71:59728>, <built-in method recv of socket object at 0x7f6fbe51c4c8>, (65536,), {}) timed out, retry=socket.timeout
Traceback (most recent call last):
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 116, in untilConcludes
    return f(*a, **kw)
socket.timeout: timed out
2019-06-11 15:16:49,978 untilConcludes(<bound method Connection.is_active of tcp socket: 10.0.3.198:15000 <- 10.0.4.71:59728>, <bound method Connection.can_retry of tcp socket: 10.0.3.198:15000 <- 10.0.4.71:59728>, <built-in method recv of socket object at 0x7f6fbe51c4c8>, (65536,), {}) timed out, retry=socket.timeout
Traceback (most recent call last):
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 116, in untilConcludes
    return f(*a, **kw)
socket.timeout: timed out
2019-06-11 15:16:50,078 untilConcludes(<bound method Connection.is_active of tcp socket: 10.0.3.198:15000 <- 10.0.4.71:59728>, <bound method Connection.can_retry of tcp socket: 10.0.3.198:15000 <- 10.0.4.71:59728>, <built-in method recv of socket object at 0x7f6fbe51c4c8>, (65536,), {}) timed out, retry=socket.timeout
Traceback (most recent call last):
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 116, in untilConcludes
    return f(*a, **kw)
socket.timeout: timed out


But I also saw the below traceback after A while

Traceback (most recent call last):
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 116, in untilConcludes
    return f(*a, **kw)
OSError: [Errno 9] Bad file descriptor

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib64/python3.7/site-packages/xpra/net/protocol.py", line 643, in _io_thread_loop
    while not self._closed and callback():
  File "/usr/lib64/python3.7/site-packages/xpra/net/protocol.py", line 722, in _read
    buf = self._conn.read(self.read_buffer_size)
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 327, in read
    return self._read(self._socket.recv, n)
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 197, in _read
    r = self.untilConcludes(*args)
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 182, in untilConcludes
    return untilConcludes(self.is_active, self.can_retry, *args)
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 118, in untilConcludes
    retry = can_retry_cb(e)
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 179, in can_retry
    return can_retry(e)
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 106, in can_retry
    raise ConnectionClosedException(e)
xpra.net.common.ConnectionClosedException: [Errno 9] Bad file descriptor
2019-06-11 15:16:51,728 connection lost: invalid packet format, HTTP GET request
2019-06-11 15:16:51,728 Protocol.close() closed=True, connection=None


Note - once you start the xpra server, connect immediately via the HTML 5 client.

comment:3 Changed 2 months ago by Antoine Martin

Owner: changed from Antoine Martin to zaveri
Status: reopenednew

Note - once you start the xpra server, connect immediately via the HTML 5 client.

I do this hundreds of times a day..

There are a lot of details missing, please see wiki/ReportingBugs.
In particular: full command lines used, type of network connection, etc.
Can you reproduce with older versions? (ie: 2.4.x in particular? anything before #2121)
Can you reproduce with the regular python client?
Is this running on a virtual machine? What kind? What host OS? What (paravirtualized?) network drivers?
Please include the server's -d network debug output of a single failed connection attempt. (from New tcp connection received to Disconnecting client)

The socket.timeout is harmless and should not be visible without enabling debug logging.
The ConnectionClosedException is the result of a closed connection and is not in itself a bug.
This looks directly related to #2315.
It might be useful to have a tcpdump trace of those connection failures.

Last edited 2 months ago by Antoine Martin (previous) (diff)

comment:4 Changed 2 months ago by zaveri


We did another repro with the following xpra version-v3.0-r22922.

Using a Fed 30 VM, winswitch beta repo launch the server with the below command.

xpra --no-daemon --bind-tcp=0.0.0.0:14000 --start=xterm start :14 --sharing=yes -d network

The Server starts up, and when we see the 'xpra is ready' output from the server output, we then use Chrome 74 on a Windows 7 machine to connect to http://IP:14000.

From the point of XPRA is ready until the first traceback, here are the logs from the server.

2019-06-13 10:54:18,647 xpra is ready.
2019-06-13 10:54:25,141 printer forwarding enabled using postscript and pdf
2019-06-13 10:54:25,149 reply_handler()
2019-06-13 10:54:25,149 update_txt({'display': ':12', 'username': 'maint', ', 'name': 'xterm', 'clients': 0}) done
2019-06-13 10:54:25,151 reply_handler()
2019-06-13 10:54:25,151 update_txt({'display': ':12', 'username': 'maint', ', 'name': 'xterm', 'clients': 0}) done
2019-06-13 10:54:25,152 reply_handler()
2019-06-13 10:54:25,152 update_txt({'display': ':12', 'username': 'maint', ', 'name': 'xterm', 'clients': 0}) done
2019-06-13 10:54:25,155 watching for applications menu changes in:
2019-06-13 10:54:25,156  '/usr/local/share/applications'
2019-06-13 10:54:25,156  '/usr/share/applications'
2019-06-13 10:54:25,267 5.8GB of system memory
2019-06-13 10:54:27,945 peer: (0, -1, -1)
2019-06-13 10:54:27,945 new_connection((<flags G_IO_IN of type GLib.IOCondiEAM, proto=0, laddr=('0.0.0.0', 12000)>)) sock=<socket.socket fd=26, family 12000), raddr=('10.0.4.50', 59934)>, socket_info=('0.0.0.0', 12000), timeo
2019-06-13 10:54:27,946 SocketConnection(<socket.socket fd=26, family=Addre), raddr=('10.0.4.50', 59934)>, ('10.0.3.198', 12000), ('10.0.4.50', 59934)
2019-06-13 10:54:27,946 Connection(('10.0.4.50', 59934), 'tcp', None)
2019-06-13 10:54:27,946 handle_new_connection(tcp socket: 10.0.3.198:12000 tKind.SOCK_STREAM, proto=0, laddr=('10.0.3.198', 12000), raddr=('10.0.4.50'sockname=('10.0.3.198', 12000), target=('10.0.4.50', 59934)
2019-06-13 10:54:28,998 socket tcp socket: 10.0.3.198:12000 <- 10.0.4.50:59
2019-06-13 10:54:28,998 may_wrap_socket: no data, not wrapping
2019-06-13 10:54:28,998 may_wrap_socket(..)=(True, tcp socket: 10.0.3.198:1
2019-06-13 10:54:28,998 log_new_connection(tcp socket: 10.0.3.198:12000 <- ction'>, sock=<socket.socket fd=26, family=AddressFamily.AF_INET, type=Sock4)>, sockname=('10.0.3.198', 12000), address=('10.0.4.50', 59934), peername
2019-06-13 10:54:28,998 New tcp connection received from 10.0.4.50:59934 on
2019-06-13 10:54:28,998 make_protocol(tcp, tcp socket: 10.0.3.198:12000 <- t 0x7fae18dff0d0>)
2019-06-13 10:54:28,999 io_thread_loop(read, <bound method Protocol._read o
2019-06-13 10:54:29,099 untilConcludes(<bound method Connection.is_active oetry of tcp socket: 10.0.3.198:12000 <- 10.0.4.50:59934>, <built-in method meout
Traceback (most recent call last):
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 1
    return f(*a, **kw)
socket.timeout: timed out
2019-06-13 10:54:29,199 untilConcludes(<bound method Connection.is_active oetry of tcp socket: 10.0.3.198:12000 <- 10.0.4.50:59934>, <built-in method meout

Using the Python Client Xpra-x86_64_Setup_3.0-r22817, we get the below logs and the same behaviour as the HTML 5 Client.

2019-06-13 15:57:12,476 xpra is ready.
2019-06-13 15:57:18,667 printer forwarding enabled using postscript and pdf
2019-06-13 15:57:18,674 reply_handler()
2019-06-13 15:57:18,675 update_txt({'display': ':12', 'username': 'maint', 'uuid': '016df33c68354c4fb37511c3dbc73056', 'platform': 'linux', 'type': 'seamless', 'name': 'xterm', 'clients': 0}) done
2019-06-13 15:57:18,675 reply_handler()
2019-06-13 15:57:18,675 update_txt({'display': ':12', 'username': 'maint', 'uuid': '016df33c68354c4fb37511c3dbc73056', 'platform': 'linux', 'type': 'seamless', 'name': 'xterm', 'clients': 0}) done
2019-06-13 15:57:18,675 reply_handler()
2019-06-13 15:57:18,675 update_txt({'display': ':12', 'username': 'maint', 'uuid': '016df33c68354c4fb37511c3dbc73056', 'platform': 'linux', 'type': 'seamless', 'name': 'xterm', 'clients': 0}) done
2019-06-13 15:57:18,680 watching for applications menu changes in:
2019-06-13 15:57:18,680  '/usr/local/share/applications'
2019-06-13 15:57:18,680  '/usr/share/applications'
2019-06-13 15:57:18,791 5.8GB of system memory
2019-06-13 15:57:19,364 peer: (0, -1, -1)
2019-06-13 15:57:19,365 new_connection((<flags G_IO_IN of type GLib.IOCondition>, <socket.socket fd=4, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('0.0.0.0', 12000)>)) sock=<socket.socket fd=26, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('10.0.3.198', 12000), raddr=('10.0.4.50', 50982)>, socket_info=('0.0.0.0', 12000), timeout=0.1, address=('10.0.4.50', 50982), peername=('10.0.4.50', 50982). timeout=0.1
2019-06-13 15:57:19,365 SocketConnection(<socket.socket fd=26, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('10.0.3.198', 12000), raddr=('10.0.4.50', 50982)>, ('10.0.3.198', 12000), ('10.0.4.50', 50982), ('10.0.4.50', 50982), 'tcp', None)
2019-06-13 15:57:19,365 Connection(('10.0.4.50', 50982), 'tcp', None)
2019-06-13 15:57:19,365 handle_new_connection(tcp socket: 10.0.3.198:12000 <- 10.0.4.50:50982, <socket.socket fd=26, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('10.0.3.198', 12000), raddr=('10.0.4.50', 50982)>, ('10.0.4.50', 50982), 'tcp', ('10.0.4.50', 50982), ('0.0.0.0', 12000)) sockname=('10.0.3.198', 12000), target=('10.0.4.50', 50982)
2019-06-13 15:57:20,417 socket tcp socket: 10.0.3.198:12000 <- 10.0.4.50:50982 peek: got 0 bytes
2019-06-13 15:57:20,417 may_wrap_socket: no data, not wrapping
2019-06-13 15:57:20,417 may_wrap_socket(..)=(True, tcp socket: 10.0.3.198:12000 <- 10.0.4.50:50982, b'')
2019-06-13 15:57:20,417 log_new_connection(tcp socket: 10.0.3.198:12000 <- 10.0.4.50:50982, ('0.0.0.0', 12000)) type=<class 'xpra.net.bytestreams.SocketConnection'>, sock=<socket.socket fd=26, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('10.0.3.198', 12000), raddr=('10.0.4.50', 50982)>, sockname=('10.0.3.198', 12000), address=('10.0.4.50', 50982), peername=('10.0.4.50', 50982)
2019-06-13 15:57:20,417 New tcp connection received from 10.0.4.50:50982 on 0.0.0.0:12000
2019-06-13 15:57:20,417 make_protocol(tcp, tcp socket: 10.0.3.198:12000 <- 10.0.4.50:50982, <function ServerCore.make_protocol.<locals>.xpra_protocol_class at 0x7f20063c00d0>)
2019-06-13 15:57:20,418 io_thread_loop(read, <bound method Protocol._read of Protocol(tcp socket: 10.0.3.198:12000 <- 10.0.4.50:50982)>) loop starting
2019-06-13 15:57:20,518 untilConcludes(<bound method Connection.is_active of tcp socket: 10.0.3.198:12000 <- 10.0.4.50:50982>, <bound method Connection.can_retry of tcp socket: 10.0.3.198:12000 <- 10.0.4.50:50982>, <built-in method recv of socket object at 0x7f2008e08dc8>, (65536,), {}) timed out, retry=socket.timeout
Traceback (most recent call last):
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 116, in untilConcludes
    return f(*a, **kw)
socket.timeout: timed out

Trying to initiate the Python client through the cmd, get the below logs and the client does not connect

bled=['rencode', 'bencode']
2019-06-13 16:05:42,586 write_format_thread_loop starting
2019-06-13 16:05:42,603 next_packet() packets in queues: priority=0, ordinary=1,
 mouse=False
2019-06-13 16:05:42,618 io_thread_loop(write, <bound method Protocol._write of P
rotocol(named-pipe:namedpipe://12000/)>) loop starting
2019-06-13 16:05:42,623 pipe_write: 7473 bytes
2019-06-13 16:05:42,626 WriteFile(..)=0, len=0
2019-06-13 16:05:42,628 WriteFile: INVALID_HANDLE
2019-06-13 16:05:42,643 bwitem(<gtk.Menu object at 0x8053460 (GtkMenu at 0x3fef9
00)>, 0)
2019-06-13 16:05:42,743 io_thread_loop(read, <bound method Protocol._read of Pro
tocol(named-pipe:namedpipe://12000/)>) loop starting
2019-06-13 16:05:42,746 ReadFile(..)=0, len=0
2019-06-13 16:05:42,746 ReadFile: INVALID_HANDLE



0f\x0b\xbay\xd9',), {}) failed to write buffer to named pipe handle 184467440737
09551615, retry=False
Traceback (most recent call last):
  File "./xpra/net/bytestreams.py", line 116, in untilConcludes
  File "./xpra/platform/win32/namedpipes/connection.py", line 139, in _pipe_writ
e
Exception: failed to write buffer to named pipe handle 18446744073709551615
2019-06-13 16:06:48,214 untilConcludes(<bound method NamedPipeConnection._pipe_w
rite of named-pipe:namedpipe://12000/>, ) exception: failed to write buffer to n
amed pipe handle 18446744073709551615, error code=6
Traceback (most recent call last):
  File "./xpra/platform/win32/namedpipes/connection.py", line 85, in untilConclu
des
  File "./xpra/net/bytestreams.py", line 182, in untilConcludes
  File "./xpra/net/bytestreams.py", line 116, in untilConcludes
  File "./xpra/platform/win32/namedpipes/connection.py", line 139, in _pipe_writ
e
Exception: failed to write buffer to named pipe handle 18446744073709551615
2019-06-13 16:06:48,219 Error: write connection named-pipe:namedpipe://12000/ re
set
2019-06-13 16:06:48,221  failed to write buffer to named pipe handle 18446744073
709551615: 6
Traceback (most recent call last):
  File "./xpra/net/protocol.py", line 643, in _io_thread_loop
  File "./xpra/net/protocol.py", line 670, in _write
  File "./xpra/net/protocol.py", line 686, in write_items
  File "./xpra/net/protocol.py", line 705, in write_buffers
  File "./xpra/net/protocol.py", line 716, in con_write
  File "./xpra/platform/win32/namedpipes/connection.py", line 121, in write
  File "./xpra/net/bytestreams.py", line 190, in _write
  File "./xpra/platform/win32/namedpipes/connection.py", line 91, in untilConclu
des
IOError: failed to write buffer to named pipe handle 18446744073709551615: 6
2019-06-13 16:06:48,231 connection lost: write connection named-pipe:namedpipe:/
/12000/ reset
2019-06-13 16:06:48,231 Protocol.close() closed=False, connection=named-pipe:nam
edpipe://12000/
2019-06-13 16:06:48,234 Protocol.close() calling <bound method NamedPipeConnecti
on.close of named-pipe:namedpipe://12000/>
2019-06-13 16:06:48,234 named-pipe:namedpipe://12000/.close()
2019-06-13 16:06:48,236 terminate_queue_threads()
2019-06-13 16:06:48,239 Protocol.close() done
2019-06-13 16:06:48,239 check_server_echo(0) last=True, server_ok=True (last_pin
g_echoed_time=0)
2019-06-13 16:06:48,239 Error: failed to receive anything, not an xpra server?
2019-06-13 16:06:48,241   could also be the wrong protocol, username, password o
r port
2019-06-13 16:06:48,241   or the session was not found
2019-06-13 16:06:48,244 Connection lost
2019-06-13 16:06:48,246 Protocol.close() closed=True, connection=None
2019-06-13 16:06:48,284 WaitForSingleObject(..)=TIMEOUT, len=0
2019-06-13 16:06:48,284 pipe_read: 0 bytes

C:\Program Files\Xpra>


In both cases, the client will eventually connect. But for the python client, it will fail to connect(2/3 times failed).

Network Drivers of the VM

00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.2 USB controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01)
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 01)
00:02.0 VGA compatible controller: Device 1234:1111
00:03.0 SCSI storage controller: XenSource, Inc. Xen Platform Device (rev 02)

We will try to reproduce with some older version soon, and we may even try a tcp dump.

Changed 2 months ago by zaveri

Attachment: 2316-info.txt added

comment:5 Changed 2 months ago by zaveri

As we were performing some other testing, we found the below exception

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib64/python3.7/site-packages/xpra/net/protocol.py", line 643, in _io_thread_loop
    while not self._closed and callback():
  File "/usr/lib64/python3.7/site-packages/xpra/net/protocol.py", line 722, in _read
    buf = self._conn.read(self.read_buffer_size)
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 327, in read
    return self._read(self._socket.recv, n)
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 197, in _read
    r = self.untilConcludes(*args)
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 182, in untilConcludes
    return untilConcludes(self.is_active, self.can_retry, *args)
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 118, in untilConcludes
    retry = can_retry_cb(e)
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 179, in can_retry
    return can_retry(e)
  File "/usr/lib64/python3.7/site-packages/xpra/net/bytestreams.py", line 106, in can_retry
    raise ConnectionClosedException(e)
xpra.net.common.ConnectionClosedException: [Errno 9] Bad file descriptor
2019-06-13 16:55:19,650 connection lost: invalid packet format, HTTP GET request
2019-06-13 16:55:19,650 Protocol.close() closed=True, connection=None
2019-06-13 16:55:23,652 flush_then_close: wait_for_packet_sent() close_and_release()
2019-06-13 16:55:23,652 Protocol.close() closed=True, connection=None
2019-06-13 16:55:23,652 flush_then_close: done, callback=None

XPRA INFO -- attached txt file.

comment:6 Changed 2 months ago by Antoine Martin

First, your server command line starts on port 14000 but your client connects to port 12000.
Make sure to always include the command lines with the command output.

From the point of XPRA is ready until the first traceback, here are the logs from the server.

That traceback is normal. Do not stop there.
In debug mode, you will be seeing a lot more details, including stacktraces.
In this case, the server is triggering a timeout waiting to send or receive stuff. This is not an error, it will just retry.

2019-06-13 10:54:27,946 handle_new_connection(tcp socket: 10.0.3.198:12000 tKind.SOCK_STREAM, proto=0, laddr=('10.0.3.198', 12000), raddr=('10.0.4.50'sockname=('10.0.3.198', 12000), target=('10.0.4.50', 59934)
2019-06-13 10:54:28,998 may_wrap_socket: no data, not wrapping

What's strange here is that we should be receiving some initial data with the connection.
You can try increasing the delay to see if that helps:

XPRA_PEEK_TIMEOUT=5 xpra start ...

The default is to wait just 1 second for some data to arrive. When the server doesn't get any data, it will use the default TCP mode, which is fine for a native client but not for the html5 client.
Using bind-ws instead of bind-tcp may workaround this problem. When you do this, you can still connect the native client but you need to use a ws connection string: xpra attach ws://IP:port/.

Trying to initiate the Python client through the cmd, get the below logs and the client does not connect

You're using an invalid URI syntax, which ends up being parsed as a named-pipe: named-pipe:namedpipe://12000/.

xpra.net.common.ConnectionClosedException: [Errno 9] Bad file descriptor

This one looks harmless, with debug logging turned off it should end up being handled as a normal "connection is closed" event.

comment:7 Changed 2 months ago by Antoine Martin

Please also try with a python2 xpra server.
This could be caused by some subtle socket API change between python2 and python3.

comment:8 Changed 2 months ago by Antoine Martin

Another thing worth trying is to host the xpra html5 client on a separate server (apache, nginx, etc).

comment:9 Changed 5 weeks ago by Antoine Martin

Priority: majorcritical

The 3.0 release is getting closer, we need to make sure this is fixed.
(I cannot reproduce)

comment:10 Changed 3 weeks ago by Smo

Owner: changed from zaveri to Antoine Martin

I've tried to reproduce this multiple ways with different clients including windows.

I can't seem to find a way to get this error so I believe this should be closed for now until it shows up again.

Last edited 3 weeks ago by Smo (previous) (diff)

comment:11 Changed 3 weeks ago by Antoine Martin

Resolution: worksforme
Status: newclosed

Thanks.

Note: See TracTickets for help on using tickets.