I am afraid I don't have good news for you. When that feature was added, it was not fully appreciated how it would interact in cases with multiple tornado threads, or scaled out servers behind a load balancer. In those situations hard crashes can occur, because the initial HTTP connection (with request info) and the follow-on WS connection can end up on different processes. In which event the second process does not have the request, and attempting to access the non-existent request results in an exception. You can see all the details here:
Since the initial issue that prompted adding requests was actually only for "?foo=10" style request arguments, and there was a straightforward technical means to save just that capability, while fixing the crashes, that is what we did. I had hoped that since the full request access was only present briefly, and was never really advertised, that it would not affect anyone. (Unfortunately not the case)
I don't really have a good solution. Solving this in general means solving the hard problem described in that issue.
I suppose one option would be to add an option to turn on the old behavior, but only when asked for. Then if it is enabled with --num-threads other then 1 the server could just detect and abort immediately with a message. There's no way to detect that in the multiple server/load balancer case, so I would still worry about a burden of bug reports when users tried to scale out and turn the option on at the same time. But I would consider accepting a PR to do that, though, if you are interested in making one.
Otherwise for now your best bet is probably to do some kind of monkey patching. Here is the change that turned off everything but request args:
Basically it wraps the request in a _RequestProxy that limits access. If you replace the class _RequestProxy with an identity function then AFAIK he original request will get attached to the context again (which will work in the single threaded case and fall over otherwise). To do this you will probably need to start the server programmatically (so you can patch before things are run), e.g. like in this example:
Though it's possible a server startup lifecycle hook would be early enough to do the patching.
Wish I had better information to relay.
On Jun 21, 2017, at 06:56, [email protected] wrote:
I have been developing an app with Bokeh 0.12.4.
The app relies on several parameters extracted from the curdoc().session_context.request, namely request.protocol, request.host, request.uri and request.arguments.
After upgrading to 0.12.6, the app no longer functions, and it seems that request.protocol, request.host and request.uri are no longer exposed.
Can you give me any pointers on how to access that information with the latest codebase?
You received this message because you are subscribed to the Google Groups "Bokeh Discussion - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/6387d25c-59f3-4bd2-aad9-d0be8c1a5851%40continuum.io.
For more options, visit https://groups.google.com/a/continuum.io/d/optout.