> 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-li...@jan-kohnert.de>:
>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: users-unsubscr...@httpd.apache.org
>For additional commands, e-mail: users-h...@httpd.apache.org
>
