WebSockets don't work on Apache

[FooBarWidget]

If the response has the chunked transfer encoding, then WebSockets handshakes become corrupted. See https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/phusion-passenger/XtjxA8E1idw/Z029OysamjsJ for the report.

[FooBarWidget]

See also phusion/passenger-nodejs-websocket-demo#2

[FooBarWidget]

The chunked encoding problem can be solved by setting Content-Length: 0 in the response, which will prevent Apache from setting Transfer-Encoding.

// Process WebSocket upgrade.
Header upgrade = lookupHeader(headerData, "Upgrade", "upgrade");
if (!upgrade.empty()) {
    RH_TRACE(client, 2, "WebSocket upgrade detected.");
    headerData.append("Content-Length: 0\r\n");
}

However, it looks like the problem is more complicated than just solving this. The current Apache module currently does not support simultaneously forwarding request data and response data, so WebSockets still doesn't work. Worse, instead of triggering an error, the connection just freezes.

Fixing this is non-trivial. I'm postponing it to a later release.

[captn3m0]

👍 Waiting for this eagerly.

[kiranos]

+1

[kiranos]

any news on this?

[FooBarWidget]

Unfortunately not. If you need WebSockets, for the time being we recommend using Nginx, or using Passenger Standalone behind Apache + mod_proxy.

[vanboom]

See phusion/passenger-ruby-websocket-demo#2, appears WebSockets are still not working under Apache mod_passenger in 5.0.18? (It's very possible that I am doing something wrong in my Apache .conf) Thanks for Passenger - it's incredible!

[FooBarWidget]

@vanboom That is correct, WebSockets do not work yet in the Apache version. For the time being, we recommend that you use the Nginx version, or Apache + Standalone in a reverse proxy setup, if you need WebSockets.

[siegy22]

Is this a wontfix?

[CamJN]

@siegy22 not exactly, but it's blocked on the Apache project improving their module.

[annymosse]

@vanboom That is correct, WebSockets do not work yet in the Apache version. For the time being, we recommend that you use the Nginx version, or Apache + Standalone in a reverse proxy setup, if you need WebSockets.

@FooBarWidget
how can i do it (Apache + Standalone in a reverse proxy setup)?"still newer in servers configs"

[mk-pmb]

@annymosse
How to install Passenger Standalone
Once you have that running, it gives a web server. You'll want to ensure it is not reachable directly from the outside. To achieve this, you can use explicit interface binding (to a non-public interface) and/or firewall rules.
The Apache Reverse Proxy Guide shows how to make a publicly reachable apache forward traffic for some parts of your URL space, to the guarded private Passenger server.

[beppe9000]

Does this apply to cpanel ?

[deltafactory]

@beppe9000 Yes, since cPanel's default web server is Apache.

[mjobin-mdsol]

@CamJN

not exactly, but it's blocked on the Apache project improving their module.

is there an open issue on Apache's side we can track?

[mjones-vsat]

Any updates on this?

[mk-pmb]

Sorry for the wrong info earlier. Seems like apache itself still supports prefork worker mpm, just my hosting management software doesn't.

[mjones-vsat]

Is there some Apache issue that we can refer to that will unblock this?

[omar391]

how about this: https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html

[CamJN]

mod proxy wstunnel forces you to specify a separate target for your ws traffic. Essentially you need something listening on another port than the main http port, which will handle your ws traffic. I'm fairly certain that limitation is why people want a better solution.

[strugee]

I don't believe that's true. You don't need a separate port, just a separate path. This snippet, for example, is working just fine for me in production:

# Proxy WebSocket requests to /stream
ProxyPass /stream ws://127.0.0.1:56488/stream retry=0 timeout=5

# Proxy all other requests requests to /
ProxyPass / http://127.0.0.1:56488/ retry=0 timeout=5
ProxyPassReverse / http://127.0.0.1:56488/

[mjobin-mdsol]

what ? I can use Apache with Rails ActionCable now ?

@strugee you are a life saver... I had long forgotten about this...

[sudoremo]

I don't believe that's true. You don't need a separate port, just a separate path. This snippet, for example, is working just fine for me in production:

# Proxy WebSocket requests to /stream
ProxyPass /stream ws://127.0.0.1:56488/stream retry=0 timeout=5

# Proxy all other requests requests to /
ProxyPass / http://127.0.0.1:56488/ retry=0 timeout=5
ProxyPassReverse / http://127.0.0.1:56488/

Just to clarify: The actual WebSockets-endpoint is also delivered by Passenger, and not a separate process? In the past, I had to use a separate puma process, on a separate port, to facilitate WS with Apache.

[strugee]

I can't comment on Passenger support as I haven't used it for years. I was talking strictly about generic Apache mod_proxy and mod_proxy_ws.

[Gu7z]

Almost 10 years, has there been any progress or alternative solutions explored over, besides resorting to running a parallel server and rewriting routes in Apache?

[mjobin-mdsol]

I'm sure very sad when I have to move away from the Apache module when an app starts using WebSocket.