Proxied, HTML-embedded script request of Bokeh ...autoload.js?bokeh-autoload-element... timing out

Those who followed my previous posts will recall that I am embedding an existing Bokeh app in a web page that is being served by a Docker container. The problem I’m encountering now is, now that I’ve proxied the embedding web page,* the HTML-embedded script “call” of …/autoload.js?bokeh-autoload-element=… fails to return, and so times out.**

I can verify*** that the HTML-embedded script request is being proxy-passed to the correct port (5006) at the correct IP address; but aside from that there is no indication that the request is ever handled. With --log-level debug set, no connections or sessions are ever reported, before, while, or after the proxied request is issued and has timed out:

Coronagraph | 2017-05-01 04:30:04,390 [pid 11] 0 clients connected

Coronagraph | 2017-05-01 04:30:04,391 [pid 11] /coron_model has 0 sessions with 0 unused

Has anyone else attempted to do what I’m doing, and/or encountered this situation? Do I have something configured wrong for this situation?

  • For security purposes, which require that only one port, namely the system’s Ngnix reverse proxy server, be accessible externally — FWIW, this proxying is managed by J. Wilder’s nginx-proxy Docker container.

** At the default 60 sec. mark; note that in the prior, non-proxied configuration, this request typically returned within 5 secs.

*** Via upstream access logging, within the proxying location stanza, using

log_format upstreamlog ‘[$time_local] $remote_addr - $remote_user - $server_name to: $upstream_addr: $request upstream_response_time $upstream_response_time msec $msec request_time $request_time’;

E.g.: [01/May/2017:04:03:32 +0000] 172.18.0.5 - - - to: 172.18.0.3:5006: GET /coron_model/autoload.js?bokeh-autoload-element=8e75cc5e-94f8-4886-b1c1-fbfcda678d63 HTTP/1.1 upstream_response_time 60.054 msec 1493611412.408 request_time 60.054

Configuration details follow.

···

———————

Here is how I’m serving the app (via shell script):

bokeh serve /coronagraph/apps/coron_model.py --port 5006 --use-xheaders \

–host=“*” --allow-websocket-origin 127.0.0.1

Here is how I obtain the embedding script:

autoload_server(model=None, app_path=“/coron_model”, url=“http://coronagraph”)

Here is an example of the returned embedding script:

<script

src=“http://coronagraph/coron_model/autoload.js?bokeh-autoload-element=8e75cc5e-94f8-4886-b1c1-fbfcda678d63

id=“8e75cc5e-94f8-4886-b1c1-fbfcda678d63”

data-bokeh-model-id=“”

data-bokeh-doc-id=“”

And here is my Nginx proxying rule for the …/coron_model/autoload.js?bokeh-autoload-element=… request:

location ~ ^/coron_model

{

proxy_pass http://coronagraph:5006;

access_log /var/log/nginx/access.log upstreamlog;

proxy_set_header Host $host;

proxy_set_header X-Forwarded-Proto $scheme;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_pass_header Server;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Scheme $scheme;

proxy_buffering off;

proxy_redirect off;

proxy_http_version 1.1;

proxy_set_header Upgrade $http_upgrade;

proxy_set_header Connection “upgrade”;

}

P.S. The Bokeh app is running under 0.12.4, installed (under miniconda) with:

conda install bokeh=0.12.4

``

Well, I figured it out. It turns out that the recently-discovered incompatibility of Bokeh 0.12.5 with Tornado 4.5.1 exists in Bokeh 0.12.4 as well. Realizing this might be the case, I reverted Tornado to 4.4.2:

conda install -c anaconda tornado=4.4.2

``

and my app embedding works just fine now!