Open yungxiaomcc opened 1 year ago
This was most-likely an oversight when migrating wslink to v1. But in practice changing that endpoint should not be required. For real-world deployment, a pvw process tends to be ran in an internal network with a proxy that rewrite all those url to be session based.
I use nginx to forward external request to internal visualizer process with prefix like "proxr/abc/", when opened the url (should be "http://{{host}}:{{port}}/proxr/abc/index.html"),but the ws connection url is wrong which is "ws://{{host}}:{{port}}/ws". Maybe this is cause of front-end building option of "publicPath" (not sure),so i try to change "ws-endpoint" to make it work. Plz help me out this issue.
I use nginx to forward external request to internal visualizer process with prefix like "proxr/abc/", when opened the url (should be "http://{{host}}:{{port}}/proxr/abc/index.html"),but the ws connection url is wrong which is "ws://{{host}}:{{port}}/ws". Maybe this is cause of front-end building option of "publicPath" (not sure),so i try to change "ws-endpoint" to make it work. Plz help me out this issue.
I use paraview.apps.trame as running module, it works well in my app.
So you don't need to change it via ws-endpoint. Just add that info in the URL like http://{{host}}:{{port}}/proxr/abc/index.html?sessionURL=ws://......
The way we do the routing with Apache and our launcher is by doing that and having the launcher properly providing that sessionURL internally with the session information.
Anyway, it seems that you just need to configure your launcher...
So you don't need to change it via ws-endpoint. Just add that info in the URL like
http://{{host}}:{{port}}/proxr/abc/index.html?sessionURL=ws://......
The way we do the routing with Apache and our launcher is by doing that and having the launcher properly providing that sessionURL internally with the session information.
Anyway, it seems that you just need to configure your launcher...
I have updated my configration as you siad, and it worked. Thanks!
High-level description
"--ws-endpoint", the startup option, take no effect.
Steps to reproduce
Detailed behavior
Expected behavior
the websocket url should be ws://192.10.10.10:9087/foo/bar/ws
Environment