Am Dienstag, 27. Dezember 2022, 20:32:28 CET schrieb Florian Schwalm:
> 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.
True, I just tried it again, using your suggestion:
> 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]
Using this configuration results in a 400 error in Apache's logs, and I cannot
find a corresponding log entry in GitLab's logs:
$REMOTE_IP - - [27/Dec/2022:21:22:16 +0100] "GET /-/cable HTTP/1.1" 400 30 "-"
"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/108.0.0.0 Safari/537.36"
> The mod_proxy_wstunnel docs also use the L or last flag for the RewriteRule,
> so maybe also add this if necessary.
As far as I understood, the "P" flag implies "L", but regardless whether I set
"L" or not, the behaviour stays the same. If I remove the "NE" flag, the DSO
error returns, so I think, I at least have to set "P,NE"
> 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
Reading through the report, this bug probably hit me, too. GitLab is a Ruby-
on-rails application using a Puma Webserver internally, connected to Apache
all over UNIX-sockets; this cable-stuff mentioned in the report is RoR's
action cable that is used in GitLab, too. And basically the "working" solution
I found, too; I'm not quite sure whether using two Location directives in my
config makes a difference over giving the location directly to ProxyPass...
Thanks, again!
--
MfG Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
