Problem with websocket and my reverse proxy

[canoine]

Hello,

I meet a problem with the last(s) Commafeed version(s) (how many ?) I ran home. It seems the websocket communications between my browser and my server work well directly, but not through my Apache reverse proxy. And I don't know why at all.

As I don't understand a goddamn thing about websockets, I don't even know how to get traces to see what is exchanged between the browser and the server. So... heeeeelp, pleeeaaaase !

Context :

• Server : Commafeed 3.3.1 self-compiled and self-hosted,
• Proxy : Apache 2.4.55 with mod_proxy and mod_proxy_wstunnel loaded,
• Browser : Firefox 113.

Main problem : through my proxy, the browser loops on the websocket loading part. It seems it doesn't switch to websocket after receiving the HTTP 101 response :

The reverse proxy configuration (with several commented tries. Nothing works, anyway) :

<VirtualHost _default_:443>
       Define HOTE <supprimé>.org

       ServerName ${HOTE}
       UseCanonicalName On

       ## Certificat
       SSLCertificateFile /etc/ssl/apache/${HOTE}/fullchain.pem
       SSLCertificateKeyFile /etc/ssl/apache/${HOTE}/key.pem

       <IfDefine PROXY>
       <IfModule mod_proxy.c>
               ProxyRequests Off
               ProxyVia Block
               ProxyErrorOverride On
               ProxyTimeout 60
               ProxyPreserveHost On

               #ProxyPass / http://<supprimé>:8082/ upgrade=websocket disablereuse=on
               #ProxyPass /ws http://<supprimé>:8082/ws upgrade=websocket
               #ProxyWebsocketFallbackToProxyHttp Off
               ProxyPass /ws ws://<supprimé>:8082/ws

#               ProxyPassReverse /ws http://<supprimé>:8082/ws upgrade=websocket
               ProxyPassReverse /ws ws://<supprimé>:8082/ws

#               RewriteEngine On
#               RewriteCond %{HTTP:Connection} Upgrade [NC]
#               RewriteCond %{HTTP:Upgrade} websocket [NC]
#               RewriteRule /(.*) ws://<supprimé>:8082/$1  [P,L]

               ProxyPass / http://<supprimé>:8082/ disablereuse=on
               ProxyPassReverse / http://<supprimé>:8082/

               <Proxy *>
                       Require all granted
               </Proxy>
       </IfModule>
       </IfDefine>
</VirtualHost>

Auxiliary problem 1 : as the changelog says there were database changes, I'd have to restore an old database dump to revert the update, and, as a good old lazy sysadmin, If I could avoid doing that, I'll be fine. :)

Auxiliary problem 2 : even in a no-proxy context, I have to start Firefox with a new fresh profile to get some interesting information. Everytime. It seems Firefox keeps data somewhere locally, even after a serious flush (clearing history, local cache, sessions, and so on), so as of the second run, Firefox shows nothing related to websockets at all.

First load :

Second load :

Third load, after a cache/history flush :

Auxiliary problem 2 bis : due to this behaviour, using Commafeed with my usual Firefox profile, even through my reverse proxy, works like a charm. My wife detectd the problem because of a new profile. So I don't know when it appeared. Yesterday ? One, two, three days before ? As there are several updates every day, I can't be more precise, unfortunately. But all worked well last week, she says.

Finally, I don't even know where the problem is. A reverse proxy misconfiguration ? An apache bug ? A misunderstanding of how these goddamn websockets work ? A java/javascript/whatever dependency issue ? Some of them together ?

Any clue is welcome. :)

[Athou]

Oh it's been a while since I had to deal with Apache. I know how to do it with nginx though.

Is using Caddy instead of Apache an option?

For example, caddy reverse-proxy --from commafeed.mywebsite.com --to localhost:8082 will configure everything, even the websocket connection, and will enable HTTPS with Letsencrypt automatically.

[canoine]

Caddy ? I didn't know it. As I like to keep the control of my computers, I'm not a fan of the "full-auto-configured" coffee-makers, but let's give it a try. :)
Migrating to nginx is on my todo-list for years, but did I already say I'm a lazy sysadmin ?

[canoine]

Ouch.

# emerge -pv caddy
(snip)
Total: 3 packages (3 new), Size of downloads: 124 541 KiB

# emerge -pv nginx
(snip)
Total: 5 packages (4 new, 1 reinstall), Size of downloads: 1 154 KiB

That said, the problem is definitely Apache. I set up a fast-confiigured nginx reverse proxy to test, and it works. Very well, moreover.
Let's go to reduce my todo-list...

[canoine]

Done. Certainly not optimized, but that works. So long, Apache, we'll miss you... T_T

server {
        listen xx:443 ssl;
        listen yy:443 ssl;
        listen zz:443 ssl;
        server_name <supprimé>.org;

        ssl_certificate         /etc/ssl/letsencrypt/<supprimé>/fullchain.pem;
        ssl_certificate_key     /etc/ssl/letsencrypt/<supprimé>/key.pem;
        ssl_prefer_server_ciphers on;

        include /etc/nginx/perso/headers.conf;

        location / {
                proxy_pass http://<supprimé>:8082/;
                include /etc/nginx/perso/proxy.conf;
        }
        location /ws {
                proxy_pass http://<supprimé>:8082/;
                include /etc/nginx/perso/proxy.conf;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
        }
}