On Tue, Jan 17, 2017 at 6:23 PM, Dan Trainor <dtrai...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
