Request to forwarded port doesn't finish after response was recieved

Hi, awesome product!

Just have a slight glitch.

So, I'm using code-tunnel.service on a Debian GNU/Linux 12 box in my home and I connect via the browser to it.

All goes well and ports are forwarded correctly, however I can't figure out why all requests sent to the forwarded port seem to succeed first and fail later.

Let me try to explain and demonstrate:

echo '<?= "Hello World!" ?>' > index.php
php -S 0.0.0.0:8888

The above opens up port 8888 and forwards it to: https://<some-random-chars>-8888.euw.devtunnels.ms.

I visit the link and see the request being resolved to a status of 200 instantly, and the response contains the expected content. But the browser is still loading the page.

Then a minute or so later, the same request that earlier responded with a 200, is now being reported as (failed)net::ERR_HTTP2_PROTOCOL_ERROR.

The request timings look like so:

This happens with all requests on any browser (even in incognito - after I login ofcourse), on VSCode insiders version too, and the request always takes exactly 1 minute.

The logs while this is happing look like so (I omitted some russh::client::encrypted and russh::server::kex entries below):

Feb 21 17:48:23 szbcs code[729]: [2025-02-21 17:48:23] info [tunnels::connections::relay_tunnel_host] Opened new client on channel 36
Feb 21 17:48:23 szbcs code[729]: [2025-02-21 17:48:23] debug [tunnels::connections::relay_tunnel_host] starting to serve host relay client session
Feb 21 17:48:23 szbcs code[729]: [2025-02-21 17:48:23] info [russh::server] wrote id
Feb 21 17:48:23 szbcs code[729]: [2025-02-21 17:48:23] debug [russh::ssh_read] read_ssh_id: reading
Feb 21 17:48:23 szbcs code[729]: [2025-02-21 17:48:23] debug [russh::ssh_read] read 39
Feb 21 17:48:23 szbcs code[729]: [2025-02-21 17:48:23] debug [russh::ssh_read] Ok("SSH-2.0-Microsoft.DevTunnels.Ssh_3.12\r\n")
Feb 21 17:48:23 szbcs code[729]: [2025-02-21 17:48:23] info [russh::server] read other id
Feb 21 17:48:23 szbcs code[729]: [2025-02-21 17:48:23] info [russh::server] session is running
Feb 21 17:48:24 szbcs code[729]: [2025-02-21 17:48:23] debug [russh::ssh_read] id 39 39
Feb 21 17:48:24 szbcs code[729]: [2025-02-21 17:48:24] debug [russh::client::encrypted] channel_window_adjust
Feb 21 17:48:24 szbcs code[729]: [2025-02-21 17:48:24] debug [russh::client::encrypted] amount: 4194326
Feb 21 17:48:24 szbcs code[729]: [2025-02-21 17:48:24] debug [russh::server::encrypted] request: Ok("ssh-userauth")
Feb 21 17:48:24 szbcs code[729]: [2025-02-21 17:48:24] debug [russh::server::encrypted] name: "tunnel" Ok("ssh-connection") Ok("none")
Feb 21 17:48:24 szbcs code[729]: [2025-02-21 17:48:24] debug [tunnels::connections::relay_tunnel_host] host relay client session successfully authed
Feb 21 17:48:24 szbcs code[729]: [2025-02-21 17:48:24] debug [tunnels::connections::relay_tunnel_host] Forwarded connection to port 8888
Feb 21 17:48:24 szbcs code[729]: [2025-02-21 17:48:24] debug [tunnels::connections::relay_tunnel_host] EOF from TCP stream, ending
Feb 21 17:49:13 szbcs code[729]: [2025-02-21 17:49:13] debug [tunnels::connections::ws] received liveness pong
Feb 21 17:49:23 szbcs code[729]: [2025-02-21 17:49:23] debug [russh::client::encrypted] channel_close
Feb 21 17:49:23 szbcs code[729]: [2025-02-21 17:49:23] debug [russh::server::encrypted] handler.channel_close ChannelId(2)
Feb 21 17:49:23 szbcs code[729]: [2025-02-21 17:49:23] debug [russh::server::session] break
Feb 21 17:49:23 szbcs code[729]: [2025-02-21 17:49:23] debug [russh::server::session] disconnected

• EOF from TCP stream, ending is when I recieve the 200 status code.
• disconnected is when the same request turns into a (failed)net::ERR_HTTP2_PROTOCOL_ERROR

This is surely not expected behaviour, is it? Any help on the matter would be greatly appreciated.

Reproduce the forwarded-port request with Debian, PHP's server on port 8888, and the provided Dev Tunnels URL while comparing the relay_tunnel_host logs. Start with the connection lifecycle around “EOF from TCP stream, ending” and the later channel close. Done means the request remains successful without a delayed ERR_HTTP2_PROTOCOL_ERROR.