Re: [users@httpd] Proxy both HTTP, and WebSocket traffic to UNIX socket

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <nospam001-lists@xxxxxxxxxxxxxx>:
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.


[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux