No connection possible with HTML5 client via proxy

[RipperFox]

Describe the bug
Current stable (6.1.2) and beta (6.2) Debian HTML5 client installed from the packages from the custom repo
are unable to connect via proxy.

To Reproduce
Steps to reproduce the behavior:
Server:
xpra start-desktop :100 --start=xfce4-session
Proxy:
xpra proxy :20 --tcp-auth=allow --bind-tcp=0.0.0.0:9120

Connecting to the desktop on :100 fails, opening a new desktop/command won't work via the HTML5 client.

Error in the proxy log:

2024-09-01 11:08:14,823 Error: error in network packet write/format
2024-09-01 11:08:14,824  SocketProtocol._add_packet_to_queue() takes from 2 to 4 positional arguments but 7 were given
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/xpra/net/protocol/socket_handler.py", line 384, in write_format_thread_loop
    self._add_packet_to_queue(*gpc())
TypeError: SocketProtocol._add_packet_to_queue() takes from 2 to 4 positional arguments but 7 were given

System Information:

• Server OS: Debian 12.7 (bookworm)
• Client OS: Chrome Browser
• Xpra Server Version 6.2 and 6.1.2
• Xpra Client HTML5 version 16

Additional context

Connecting to a sole session which allows access directly when started via
xpra start-desktop :100 --start=xfce4-session --bind-tcp=0.0.0.0:9120
works without problems..

[totaam]

Oops, sorry about that.
The commit above is the obvious (untested) fix. I will re-test the proxy properly later.

[RipperFox]

That was quick :)
But somethings still broken: I was trying with a desktop client as well with the fix applied - I looked at the socket communication between server and proxy. Seem there's a protocol bug as the proxy can't handle the "id" request and closes the connection:

2024-09-01 17:07:22,917 read_parse_thread_loop starting
2024-09-01 17:07:22,917 processing packet hello
2024-09-01 17:07:22,918 process packet hello
2024-09-01 17:07:22,918 enable_compressor_from_caps(..) options=('none', 'lz4', 'bro...
2024-09-01 17:07:22,918 enable_compressor(lz4): <function init_lz4.<locals>.lz4_compress at 0x7f997f8e7ec0>
2024-09-01 17:07:22,918 enable_encoder_from_caps(..) options=('rencodeplus',)
2024-09-01 17:07:22,918 enable_encoder(rencodeplus): <function init_rencodeplus.<locals>.do_rencodeplus at 0x7f997f884e00>
2024-09-01 17:07:22,918 process_hello: capabilities={'digest': ('xor', 'hmac+sha512', '.......
2024-09-01 17:07:22,918 identical major.minor remote version: 6.2
2024-09-01 17:07:22,918 make_authenticators('socket', {'uui.........
2024-09-01 17:07:22,918 setup_encryption(..) for cipher= and iv=
2024-09-01 17:07:22,918 processing authentication with (), rema.......
2024-09-01 17:07:22,918 all 0 authentication modules passed
2024-09-01 17:07:22,919 accept_client(Protocol(socket soc.......
2024-09-01 17:07:22,919 set_socket_timeout(socket socket:/run/use..t>
2024-09-01 17:07:22,919 reset_server_timeout(False) server_idle_timeout=0, server_idle_timer=0

**2024-09-01 17:07:22,919 send_disconnect(Protocol(socket socket:/run/use.....ket), ("**error: invalid request, 'id' is not supported by the proxy server"**,))**

2024-09-01 17:07:22,919 flush_then_clos.....['disconnect', "error: invalid request, 'id' is not supported by the proxy server"]...
2024-09-01 17:07:22,919 flush_then_close: wait_for_write_lock()
2024-09-01 17:07:22,919 flush_then_close: acquired the write lock
2024-09-01 17:07:22,919 flush_then_close: queue is now empty, sending the last packet using encoder=<bound method 

The client never get's a hello from the server/proxy and times out..

[totaam]

Bisected down to (a huge changeset 😞 ): 4311453

[totaam]

Until I can figure out a proper fix, try 986ac24 which is equivalent to running:

XPRA_PROXY_INSTANCE_THREADED=1 xpra proxy ...

This is a viable workaround.
The performance issues with threaded mode aren't that significant if your number of connections is low.

[totaam]

I tried hard to find a better solution - every potential solution was much much worse than the original..
The GLib main loop we inherit from the parent proxy process is unusable and we can't use another one.
So in the end I had to do a partial revert.

Perhaps Python 3.13 multi-threading will give us new ways of doing the same thing?