Open Stack

On Tue, Jan 17, 2017 at 6:23 PM, Dan Trainor <dtrainor at redhat.com> wrote:
> Hi -
>
> In an attempt to work on [0], I've been playing around with proxying all the
> service API endpoints that the UI needs to communicate with, through either
> haproxy or Apache to avoid a bug[1] around how non-Chrome browsers handle
> SSL connections to different ports on the same domain.
>
> The blueprint suggests using haproxy for this, but we're currently using the
> "old" notation of listen/server, not frontend/backend.  The distinction is
> important because the ACLs that would allow any kind of proxying to
> facilitate this are only available in the latter notation.  In order to do
> this in haproxy, tripleo::haproxy would need a rewrite (looks pretty
> trivial, but likely out of scope for this).  So I'd really like to isolate
> this to UI, which is convenient since UI runs largely self-contained inside
> Apache.
>
> I've made some good progress with most all of the services, since they were
> pretty straight-forward - mod_proxy handles them just fine.  The one I'm not
> able to make work right now is the websocket service that UI uses.
> Ultimately, I see the Websocket connection get upgraded and the Websocket
> opens, but stays open indefinitely and will never see more than 0 bytes.  No
> data is transferred from the browser over the Websocket.  This connection
> hangs indefinitely, and UI does not complete any operations that depend on
> the Zaqar Websocket.
>
> Observing trace6[4] output, I can see mod_proxy_wstunnel (which relies on
> mod_proxy) make the connection, I can see Zaqar recognize the request in
> logs, the client (UI) doesn't send or receive any data from it.  It's as if
> immediately after the Upgrade[2], the persistent Websocket connection just
> dies.
>
> I've had limited success using a couple different implementations of this in
> Apache.  ProxyPass/ProxyPassReverse looks as if it should work (so long as
> mod_proxy_wstunnel is loaded), but this is not my experience.  Using a
> mod_rewrite rule[3] to force the specific Websocket proxy for a specific URI
> (/zaqar) has the same outcome.
>
> In its most simple form, the ProxyPass rule I'm attempting to use is:
>
>   ProxyPass             "/zaqar"        "ws://192.0.2.1:9000/"
>   ProxyPassReverse      "/zaqar"        "ws://192.0.2.1:9000/"

I tried that configuration, and it worked fine with a python websocket
client. I created a queue, a subscription, and was able to retrieve
notifications properly. I used Apache 2.4.23.

Is it possible that you're having a CORS issue?

> Here's Zaqar's Websocket transport answering the request, creating both a
> queue and a subscription but no data after that:

What do you mean by "no data after that"? What kind of data are you
expecting after? Just getting those 2 messages seems to indicate that
it works fine to me. Are you getting timeouts, unexpected closed
connections?

-- 
Thomas