[prev in list] [next in list] [prev in thread] [next in thread]
List: apache-httpd-users
Subject: =?US-ASCII?Q?Re=3A_=5Busers=40httpd=5D_Proxy_both_HTTP=2C_?= =?US-ASCII?Q?and_WebSocket_traffic_to_U
From: Florian Schwalm <flo () flo-films ! de>
Date: 2022-12-27 21:47:53
Message-ID: 7E29AC3F-F744-419E-9A71-D1D24EA6512A () flo-films ! de
[Download RAW message or body]
> 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@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-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
[Attachment #3 (text/html)]
<html><head></head><body>> As far as I understood, the "P" flag implies \
"L"<br><br>True, so that part of the docs seems redundant<br><br>> Reading through \
the report, this bug probably hit me, too. GitLab is a Ruby-<br>on-rails application \
using a Puma Webserver internally, connected to Apache <br>all over UNIX-sockets; \
this cable-stuff mentioned in the report is RoR's <br>action cable that is used in \
GitLab, too. And basically the "working" solution <br>I found, too; I'm not quite \
sure whether using two Location directives in my <br>config makes a difference over \
giving the location directly to ProxyPass...<br><br>So do you have a working solution \
after applying the workaround from the bugzilla ticket or is there still a 400 \
response after that?<br><br>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.<br><br><br><div \
class="gmail_quote">Am 27. Dezember 2022 21:39:30 MEZ schrieb Jan Kohnert \
<nospam001-lists@jan-kohnert.de>:<blockquote class="gmail_quote" style="margin: \
0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> \
<pre dir="auto" class="k9mail">Am Dienstag, 27. Dezember 2022, 20:32:28 CET schrieb \
Florian Schwalm:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; \
border-left: 1px solid #729fcf; padding-left: 1ex;">As far as I understand Gitlab \
sends a HTTP GET request first to ask the<br>backend to upgrade to websockets. By \
always proxying /-/cable to ws right<br>away you prevent that first upgrade request \
from succeeding which is<br>probably where the new error message originates. That's \
why the<br>mod_proxy_wstunnel docs recommend using the RewriteRule method in \
that<br>case.<br></blockquote><br>True, I just tried it again, using your \
suggestion:<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; \
border-left: 1px solid #729fcf; padding-left: 1ex;">So a working section could \
be<br><br>RewriteEngine on<br>RewriteCond %{HTTP:Upgrade} websocket \
[NC]<br>RewriteCond %{HTTP:Connection} upgrade [NC]<br>RewriteRule ^/?(.*) \
"unix:///opt/gitlab/gitlab/tmp/sockets/gitlab-<br>workhorse.socket|ws://127.0.0.1/$1" \
[P,NE]<br></blockquote><br>Using this configuration results in a 400 error in \
Apache's logs, and I cannot <br>find a corresponding log entry in GitLab's \
logs:<br><br>$REMOTE_IP - - [27/Dec/2022:21:22:16 +0100] "GET /-/cable HTTP/1.1" 400 \
30 "-" <br>"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) \
<br>Chrome/108.0.0.0 Safari/537.36"<br><br><blockquote class="gmail_quote" \
style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: \
1ex;">The mod_proxy_wstunnel docs also use the L or last flag for the \
RewriteRule,<br>so maybe also add this if necessary.<br></blockquote><br>As far as I \
understood, the "P" flag implies "L", but regardless whether I set <br>"L" or not, \
the behaviour stays the same. If I remove the "NE" flag, the DSO <br>error returns, \
so I think, I at least have to set "P,NE"<br><br><blockquote class="gmail_quote" \
style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: \
1ex;">When trying this, in combination with unix domain sockets and websockets \
you<br>may also want to consider this workaround, it's unclear to me if that \
bug<br>has already been fixed:<br><a \
href="https://bz.apache.org/bugzilla/show_bug.cgi?id=65958">https://bz.apache.org/bugzilla/show_bug.cgi?id=65958</a><br></blockquote><br>Reading \
through the report, this bug probably hit me, too. GitLab is a Ruby-<br>on-rails \
application using a Puma Webserver internally, connected to Apache <br>all over \
UNIX-sockets; this cable-stuff mentioned in the report is RoR's <br>action cable that \
is used in GitLab, too. And basically the "working" solution <br>I found, too; I'm \
not quite sure whether using two Location directives in my <br>config makes a \
difference over giving the location directly to ProxyPass...<br><br>Thanks, \
again!<br><br></pre></blockquote></div></body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic