Mailing List Archive: Proxy both HTTP, and WebSocket traffic to UNIX socket

Proxy both HTTP, and WebSocket traffic to UNIX socket

Dec 22, 2022, 5:54 AM

Post #1 of 10 (482 views)

Hello everyone,

I've set up a GitLab instance running behind an Apache HTTP-Server acting a
proxy. GitLab officially only supports NGINX as a proxy, but since my Apache
also serves different VirtualHosts, I'd rather keep the setup I have instead
of setting up another WebServer.

According to [1], and [2] I have configured my virtual host's proxy as
following:

ProxyAddHeaders On
RequestHeader add X-Forwarded-Ssl on
RequestHeader set X-Forwarded-Proto "https"

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/

So far, this is just working fine. GitLab also uses Web-Sockets, that need to
be forwarded, too. Right now using this configuration, GitLabs log show the
following, when trying to make a Web-Socket:

Started GET "/-/cable" for $REMOTE_IP at 2022-12-22 14:35:51 +0100
Started GET "/-/cable/"[non-WebSocket] for $REMOTE_IP at 2022-12-22 14:35:51
+0100
Failed to upgrade to WebSocket (REQUEST_METHOD: GET, HTTP_CONNECTION: ,
HTTP_UPGRADE: )
Finished "/-/cable/"[non-WebSocket] for $REMOTE_IP at 2022-12-22 14:35:51
+0100

So; following [3], I added:

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]

Missing the NE-Flag, as well as replacing http with ws results in a bad config
message in Apache's error logs:
[Thu Dec 22 14:34:51.093012 2022] [proxy:warn] [pid 781:tid 140179385861824]
[client $REMOTE_IP:57328] AH01144: No protocol handler was valid for the URL
/-/cable (scheme 'unix'). If you are using a DSO version of mod_proxy, make
sure the proxy submodules are included in the configuration using LoadModule.

Using the config as written shows the following in GitLab's logs:

Started GET "/proxy:http://127.0.0.1/-/cable/" for $REMOTE_IP at 2022-12-22
14:46:19 +0100
Processing by ApplicationController#route_not_found as HTML
Parameters: {"unmatched_route"=>"proxy:http:/127.0.0.1/-/cable"}
Rendered layout layouts/errors.html.haml (Duration: 2.2ms | Allocations:
600)
Completed 404 Not Found in 30ms (Views: 2.8ms | ActiveRecord: 3.5ms |
Elasticsearch: 0.0ms | Allocations: 7303)

So I assume the config is still wrong, but I could not yet find a working
solution. Anybody knows what I'm missing?

Thanks!

[1] https://docs.gitlab.com/omnibus/settings/nginx.html
[2] https://httpd.apache.org/docs/2.4/mod/mod_proxy.html
[3] https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html

--
MfG Jan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: Proxy both HTTP, and WebSocket traffic to UNIX socket [ In reply to ]

flo at flo-films

Dec 25, 2022, 1:56 AM

Post #2 of 10 (480 views)

Permalink

Specifying ws instead of http in the RewriteRule should be good.

> If you are using a DSO version of mod_proxy, make
sure the proxy submodules are included in the configuration using LoadModule.

Did you explicitly load the mod_proxy_wstunnel module as is mentioned in the error message? The error message hints that Apache doesn't know how to handle a ws:// proxy connection.

If it still doesn't work after adding a LoadModule, maybe try wss://? I'm no expert on Gitlab installations, but on a quick search I didn't find any resources mentioning plain websockets, only secure websockets.

Am 22. Dezember 2022 14:54:01 MEZ schrieb Jan Kohnert <nospam001-lists@jan-kohnert.de>:
>Hello everyone,
>
>I've set up a GitLab instance running behind an Apache HTTP-Server acting a
>proxy. GitLab officially only supports NGINX as a proxy, but since my Apache
>also serves different VirtualHosts, I'd rather keep the setup I have instead
>of setting up another WebServer.
>
>According to [1], and [2] I have configured my virtual host's proxy as
>following:
>
>ProxyAddHeaders On
>RequestHeader add X-Forwarded-Ssl on
>RequestHeader set X-Forwarded-Proto "https"
>
>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/
>
>So far, this is just working fine. GitLab also uses Web-Sockets, that need to
>be forwarded, too. Right now using this configuration, GitLabs log show the
>following, when trying to make a Web-Socket:
>
>Started GET "/-/cable" for $REMOTE_IP at 2022-12-22 14:35:51 +0100
>Started GET "/-/cable/"[non-WebSocket] for $REMOTE_IP at 2022-12-22 14:35:51
>+0100
>Failed to upgrade to WebSocket (REQUEST_METHOD: GET, HTTP_CONNECTION: ,
>HTTP_UPGRADE: )
>Finished "/-/cable/"[non-WebSocket] for $REMOTE_IP at 2022-12-22 14:35:51
>+0100
>
>So; following [3], I added:
>
>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]
>
>Missing the NE-Flag, as well as replacing http with ws results in a bad config
>message in Apache's error logs:
>[Thu Dec 22 14:34:51.093012 2022] [proxy:warn] [pid 781:tid 140179385861824]
>[client $REMOTE_IP:57328] AH01144: No protocol handler was valid for the URL
>/-/cable (scheme 'unix'). If you are using a DSO version of mod_proxy, make
>sure the proxy submodules are included in the configuration using LoadModule.
>
>Using the config as written shows the following in GitLab's logs:
>
>Started GET "/proxy:http://127.0.0.1/-/cable/" for $REMOTE_IP at 2022-12-22
>14:46:19 +0100
>Processing by ApplicationController#route_not_found as HTML
> Parameters: {"unmatched_route"=>"proxy:http:/127.0.0.1/-/cable"}
> Rendered layout layouts/errors.html.haml (Duration: 2.2ms | Allocations:
>600)
>Completed 404 Not Found in 30ms (Views: 2.8ms | ActiveRecord: 3.5ms |
>Elasticsearch: 0.0ms | Allocations: 7303)
>
>So I assume the config is still wrong, but I could not yet find a working
>solution. Anybody knows what I'm missing?
>
>Thanks!
>
>[1] https://docs.gitlab.com/omnibus/settings/nginx.html
>[2] https://httpd.apache.org/docs/2.4/mod/mod_proxy.html
>[3] https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html
>
>--
>MfG Jan
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>For additional commands, e-mail: users-help@httpd.apache.org
>

Re: Proxy both HTTP, and WebSocket traffic to UNIX socket [ In reply to ]

nospam001-lists at jan-kohnert

Dec 27, 2022, 10:38 AM

Post #3 of 10 (477 views)

Permalink

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.

--
MfG Jan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: Proxy both HTTP, and WebSocket traffic to UNIX socket [ In reply to ]

flo at flo-films

Dec 27, 2022, 11:32 AM

Post #4 of 10 (477 views)

Permalink

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@jan-kohnert.de>:
>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.
>
>--
>MfG Jan
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>For additional commands, e-mail: users-help@httpd.apache.org
>

Re: Proxy both HTTP, and WebSocket traffic to UNIX socket [ In reply to ]

nospam001-lists at jan-kohnert

Dec 27, 2022, 12:39 PM

Post #5 of 10 (477 views)

Permalink

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

Re: Proxy both HTTP, and WebSocket traffic to UNIX socket [ In reply to ]

flo at flo-films

Dec 27, 2022, 1:47 PM

Post #6 of 10 (477 views)

Permalink

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

Re: Proxy both HTTP, and WebSocket traffic to UNIX socket [ In reply to ]

nospam001-lists at jan-kohnert

Dec 28, 2022, 2:53 AM

Post #7 of 10 (471 views)

Permalink

Am Dienstag, 27. Dezember 2022, 22:47:53 CET schrieb Florian Schwalm:
> > 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?

I found [1] around Saturday, and got a (partly) working config using that. The
bug report suggests adding a (non-existing) port to the ws-pipe in the
ProxyPass directive; whether I add that or not does not change the behaviour.
In any case they're using ProxPass/ProxyPassReverse to proxy to unix sockets,
not the rewrite-solution. As far as I interpret GitLab's log, the upgrade to
Websockets occurs (but only if the cable location is written after the /-
location in the config). The request origin not allowed seems to be a CORS-
error from a misconfiguration on GitLab's side, I reported the problem over
there. I could test filtering the ORIGIN header when tunnelling to the
websocket, that might help, I'm not sure...

Using this config got me the "request origin not allowed" error from GitLab,
the 400 error only occurs using rewriting. Missing the wstunnel module
8obviouly) results in 500 errors, and the DSO-message in Apache's error log.
Using wss instead of ws in the rewriting scenario results in 500 errors and
another DSO-mesage i the log (secure connection impossible).

The config reads as:

---------------------------------------------------------------------------
RequestHeader add X-Forwarded-Ssl on
RequestHeader set X-Forwarded-Proto "https"

<Proxy *>
Require all granted
</Proxy>

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

[1] https://gist.github.com/thadeu/a29aa8413385aa82fa7007ff51ca8296

--
MfG Jan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: Proxy both HTTP, and WebSocket traffic to UNIX socket [ In reply to ]

nospam001-lists at jan-kohnert

Jan 4, 2023, 3:08 PM

Post #8 of 10 (442 views)

Permalink

Am Mittwoch, 28. Dezember 2022, 11:53:58 CET schrieb Jan Kohnert:
> The config reads as:
>
> ---------------------------------------------------------------------------
> RequestHeader add X-Forwarded-Ssl on
> RequestHeader set X-Forwarded-Proto "https"
>
> <Proxy *>
> Require all granted
> </Proxy>
>
> <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>
> ---------------------------------------------------------------------------

thanks to the help of the GitLab developers, I figured, I was missing
ProxyPreserveHost. The working configuration including websockets reads as:

---------------------------------------------------------------------------
ProxyPreserveHost on
RequestHeader add X-Forwarded-Ssl on
RequestHeader set X-Forwarded-Proto "https"

<Proxy *>
Require all granted
</Proxy>

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

--
MfG Jan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: Proxy both HTTP, and WebSocket traffic to UNIX socket [ In reply to ]

flo at flo-films

Jan 4, 2023, 3:25 PM

Post #9 of 10 (442 views)

Permalink

Nice, thank you for sharing the final result :)

Am 5. Januar 2023 00:08:07 MEZ schrieb Jan Kohnert <nospam001-lists@jan-kohnert.de>:
>Am Mittwoch, 28. Dezember 2022, 11:53:58 CET schrieb Jan Kohnert:
>> The config reads as:
>>
>> ---------------------------------------------------------------------------
>> RequestHeader add X-Forwarded-Ssl on
>> RequestHeader set X-Forwarded-Proto "https"
>>
>> <Proxy *>
>> Require all granted
>> </Proxy>
>>
>> <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>
>> ---------------------------------------------------------------------------
>
>thanks to the help of the GitLab developers, I figured, I was missing
>ProxyPreserveHost. The working configuration including websockets reads as:
>
>---------------------------------------------------------------------------
>ProxyPreserveHost on
>RequestHeader add X-Forwarded-Ssl on
>RequestHeader set X-Forwarded-Proto "https"
>
><Proxy *>
> Require all granted
></Proxy>
>
><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>
>---------------------------------------------------------------------------
>
>--
>MfG Jan
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>For additional commands, e-mail: users-help@httpd.apache.org
>

Re: Proxy both HTTP, and WebSocket traffic to UNIX socket [ In reply to ]

thumbs at apache

Jan 4, 2023, 4:14 PM

Post #10 of 10 (442 views)

Permalink

This is not needed for reverse proxies:
<Proxy *>
Require all granted
</Proxy>

On Wed, Jan 4, 2023 at 6:26 PM Florian Schwalm <flo@flo-films.de> wrote:

> Nice, thank you for sharing the final result :)
>
> Am 5. Januar 2023 00:08:07 MEZ schrieb Jan Kohnert <
> nospam001-lists@jan-kohnert.de>:
>>
>> Am Mittwoch, 28. Dezember 2022, 11:53:58 CET schrieb Jan Kohnert:
>>
>>> The config reads as:
>>> ------------------------------
>>> RequestHeader add X-Forwarded-Ssl on
>>> RequestHeader set X-Forwarded-Proto "https"
>>>
>>> <Proxy *>
>>> Require all granted
>>> </Proxy>
>>>
>>> <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>
>>> ------------------------------
>>>
>>
>> thanks to the help of the GitLab developers, I figured, I was missing
>> ProxyPreserveHost. The working configuration including websockets reads as:
>> ------------------------------
>> ProxyPreserveHost on
>> RequestHeader add X-Forwarded-Ssl on
>> RequestHeader set X-Forwarded-Proto "https"
>>
>> <Proxy *>
>> Require all granted
>> </Proxy>
>>
>> <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>
>> ------------------------------
>>
>>