Wt

Hello Manuel,

I haven't used Apache for this myself, we always rely on HAProxy.

Now, what I think may be happening in case of enableUpdates is that a single connection remains open longer than Apache likes (and triggers the timeout). I think that by default long polling will wait for two minutes.
In case you are using WebSockets, as to not have connections open and close constantly, you'll need to ensure the singular connection can remain alive for the duration of the whole session.

I personally do NOT see the behavior of the blocked requests in case of multiple sessions. I tested by running the widget gallery locally, and the simplechat example. They both work fine for me.
The only thing I changes from your config is the proxy to run it all locally. Admittedly, since it is the same host, this will likely not cause proxy deviations.

I can only say that perhaps: <proxy>126.0.0.1/8</proxy> ought to be <proxy>127.0.0.1/8</proxy>?

Best,
Matthias

Hello Matthias,

Thank you for you answer.

I haven't used Apache for this myself, we always rely on HAProxy.

I can't switch to HAProxy easily because I have other services running with Apache and both would listen on the same ports by default (80 and 443)

Now, what I think may be happening in case of enableUpdates is that a single connection remains open longer than Apache likes (and triggers the timeout). I think that by default long polling will wait for two minutes.

I will try to find an Apache configuration in order to mitigate that.

In case you are using WebSockets

I'm not using WebSockets, I don't know if Wt uses it behind the scenes .

I can only say that perhaps: 126.0.0.1/8 ought to be 127.0.0.1/8?

I will correct that!

If I make any new discoveries I will share them here.

Thank you again.

Hello Manuel,

I can't switch to HAProxy easily
Of course, I wasn't implying you should, just saying I often use it. I always hate answers that say "just use this", even though you specifically said you wanted to use another tool.

I'm not using WebSockets, I don't know if Wt uses it behind the scenes .
It will only do so, if it is enabled. The wt_config.xml has a web-sockets configuration option to enable/disable this.

Hopefully you are able to make it work!

Best,
Matthias

Hello, we got it working!

The issue was caused by an active HTTP/2 module in Apache (which we weren’t even using). Once we disabled it, the website started working much more reliably.

We realized this because, on a clean Debian 12 installation, it worked perfectly from the start.

Thanks for the help! This thread can be closed as the issue is resolved.

Thanks for the update! Good to hear you got it working.

Could you share which module was "misbehaving"? This can be handy for posterity.

Apache http2 official module

https://httpd.apache.org/docs/2.4/mod/mod_http2.html

root@machine:~# a2dismod http2
Module http2 disabled.
To activate the new configuration, you need to run:
  systemctl restart apache2
root@machine:~# systemctl restart apache2