As far as I understand Gitlab sends a HTTP GET request first to ask the backend
to upgrade to websockets. By always proxying /-/cable to ws right away you
prevent that first upgrade request from succeeding which is probably where the
new error message originates. That's why the mod_proxy_wstunnel docs recommend
using the RewriteRule method in that case.
One thing I only now noticed is that in your rewrite section
RewriteEngine on
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteCond %{HTTP:Connection} upgrade [NC]
RewriteRule ^/?(.*) "unix:/opt/gitlab/gitlab/tmp/sockets/gitlab-
workhorse.socket|http://127.0.0.1/$1"; [P,NE]
you wrote unix:/opt where it should be unix:///opt
Can you verify if that may cause the error or is it just an error in the mail
content?
So a working section could be
RewriteEngine on
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteCond %{HTTP:Connection} upgrade [NC]
RewriteRule ^/?(.*) "unix:///opt/gitlab/gitlab/tmp/sockets/gitlab-
workhorse.socket|ws://127.0.0.1/$1" [P,NE]
The mod_proxy_wstunnel docs also use the L or last flag for the RewriteRule, so
maybe also add this if necessary.
When trying this, in combination with unix domain sockets and websockets you
may also want to consider this workaround, it's unclear to me if that bug has
already been fixed: https://bz.apache.org/bugzilla/show_bug.cgi?id=65958
Am 27. Dezember 2022 19:38:11 MEZ schrieb Jan Kohnert
<[email protected]>:
>Hi,
>
>Am Sonntag, 25. Dezember 2022, 10:56:07 CET schrieb Florian Schwalm:
>> Specifying ws instead of http in the RewriteRule should be good.
>
>thanks for the reply! I did that, that's how I got the log error. At first,
>the wstunnel-module was not installed; but installing (and loading) it did not
>change the behaviour. I suspect wstunnel using rewrites simply does not work
>correctly when it comes to tunneling websockets via UNIX sockets.
>
>I found a workaround using:
>
><Location />
> ProxyPass unix:///opt/gitlab/gitlab/tmp/sockets/gitlab-workhorse.socket|
>http://127.0.0.1/
> ProxyPassReverse unix:///opt/gitlab/gitlab/tmp/sockets/gitlab-
>workhorse.socket|http://127.0.0.1/ </Location>
>
><Location /-/cable>
> ProxyPass unix:///opt/gitlab/gitlab/tmp/sockets/gitlab-workhorse.socket|
>ws://127.0.0.1/-/cable
> ProxyPassReverse unix:///opt/gitlab/gitlab/tmp/sockets/gitlab-
>workhorse.socket|ws://127.0.0.1/-/cable
></Location>
>
>Using the ProxyPass directive makes the tunnelling working. I got another
>problem now, though: The endpoint claims:
>
>Started GET "/-/cable" for $REMOTE_IP at 2022-12-23 16:02:43 +0100
>Started GET "/-/cable/" [WebSocket] for $REMOTE_IP at 2022-12-23 16:02:43
>+0100
>Request origin not allowed: https://git.jan-kohnert.de
>Failed to upgrade to WebSocket (REQUEST_METHOD: GET, HTTP_CONNECTION: Upgrade,
>HTTP_UPGRADE: websocket)
>Finished "/-/cable/" [WebSocket] for $REMOTE_IP at 2022-12-23 16:02:43 +0100
>
>Now, the origin is my webserver, so I suspect this to be OK; there probably is
>another configuration error on GitLab's side; this probably has nothing to do
>with Apache's configuration.
>
>--
>MfG Jan
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [email protected]
>For additional commands, e-mail: [email protected]
>
