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 understood, the "P" flag implies "L"

True, so that part of the docs seems redundant

> 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...

So do you have a working solution after applying the workaround from the bugzilla ticket or is there still a 400 response after that?

In any case, what is the current state of the config? Since there were a few suggested changes since your first mail I just want to make sure we're still on the same page before investigating further ideas.


Am 27. Dezember 2022 21:39:30 MEZ schrieb Jan Kohnert <nospam001-lists@xxxxxxxxxxxxxx>:
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!


[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