There is nothing to explain to the user, because it works out of the box in all cases where a whole subdomain is proxied, because the path doesn’t matter and the websocket upgrade request is automatically detected.
It also works in in most other cases, even if there is no subdomain, beause allmost always the websockets paths are subpaths of the main application path.
So why to you prefer NOT implementing such a thing and have the users write apache conf-files by hand instead of using the Nethserver UI?
Also there is NO UI chance, so nothing gets more complicated. At most you COULD implemement a check box “detect any proxy websocktets in subpath”, but I have no idea, why someone should disable it. So my suggestion is: implement no UI change but only take my fix to correctly proxy the websockts out of the box.
I do not understand why you oppose a really simple and useful feature, which has no negative consequences. By the way: Your example would have been solved by my change also. No file editing, just create reverse proxy for ws.serverlab.ca => localhost:3000 in the Nethserver UI and problem is solved.
I can’t speak to any of the technical stuff hear but from a from a marketing point I offer NethServer with base Crostino subscription or higher to clients with idea everything can be managed via Cockpit. As the web socket fix here isn’t available as a standard option within web-admin interface I use another product that does. For my clients this makes documentation and consistent reproducible results. Just my thoughts.
The template doesn’t handle wss/ws so I forces everything to wss for simplicity.
I did a couple of tests: it works with mattermost but not with webtop.
So it’s not applicable to all scenarios.
It could be a valuable addition but it can’t be enabled on all installations without an explicit configuration by the user: I fear regressions.
It also need extra informations from the user to make it work on all scenario (eg. the path for the web socket).
In the end, I still think it’s quite an effort to add such implementation.
Again, what do you think @dev_team?
My proposed solution handled http to ws and https to wss correctly, whereas your template does not. Why did you change it? You should keep my solution.
Please post the manual matterhost-reverse-proxy.conf. Maybe matterhost needs some very special rules, which are not handled from either the original reverse-proxy nor my change, but this would be no argument for not adopting my change, since my proposition just solves most typical websockets proxy pass with no negative effects.
If you have to do a manual configuration for matterhost before my change, you are not doing worse with my change, because the Nethserver reverse-proxy-settings are to weak in both cases. But all the configuration for reverse-proxies were my change solves the problem do not need a manual configuration any more.
My change definitly works with webtop, because I am using it and created the change extra for webtop. If it does not work with your server, you might have run into the same bug as me. See Reverse proxy subdomain to secondary application Nethserver
I think the point is, that you don’t need the information from the user, which path the websockets are working on. You only need this information, if you don’t have the mod_rewrite module active, which can detect the request for protocol switch by parsing the header and takes whatever path the browser supplies, so it should work always.
I just spent a few minute to experiment a bit with the current template without changing it too much.
Happy to hear that, so in this case, it could be a simple solution transparent to the user.
Sadly, I couldn’t get it working very quickly, so any help would be really appreciated.
Do you want to hack a bit with the template and try to create a working template-custom for all scenarios?
I will gladly try it on a test machine next days.
I think, the template is working correctly. I use it for several reverse proxy items. Please give more information about the exact configuration where it does not work at your place. If you have a working manual configuration please post this.
Please keep in mind, that the template only solves the websocket problem, not all other problems which also might arise.
could you explain how you determine if you need to use the wss or the ws, you will use always ws whatever the Port 80 or 443 and whatever the http or https of the target with your template
As already said: It is impossible to solve your problem if you don’t explain your exact configuration as requested several times. What exactly did you enter in the reverse proxy entry?