Closed pmhausen closed 6 months ago
Hi Patrick,
this looks rather nifty and clean. I will merge this soon because I have pending changes I have to merge first from a different branch. I will have to cherry pick this probably.
Have a nice evening ^^
@pmhausen Could you include the new options you added into the readme.md, and maybe a small tutorial how to use Guacamole in the How To section would be a nice too since that configuration is quite special and an interesting usecase for these new features.
README - of course. Tutorial on how to use Guacamole - sorry, no. Everything necessary to install and configure can be found here: https://guacamole.apache.org/doc/gug/
I don't see having a URL path on the backend server as "special". I will write about it in the README.
Oh thank you. Sorry I didn't mean it like that. I rather meant a small "How To" using the combined "Handle_Path" with the "Backend Path". But it's not necessary.
Thanks for adding the new options to the readme. ^^
Oh - I don't use handle_path for that.
That was just a remark about what you could theoretically do now.
Like have https://some.domain/path be handled by http://192.168.0.10/different-path ...
Whoever might need this.
I'l specifically mention Tomcat in the README, because the path component really comes from the java servlet container - that's why you cannot eliminate it in the backend.
Hi Cedrik,
I was able to solve the "Guacamole problem" by adding a single field to the handler configuration dialog and Caddyfile template. I guess you'll like it, because it's rather unobtrusive, hidden behind "advanced settings" anyway, and does not add bloat to the plugin for rare edge cases.
The corresponding Caddy community dicussion that lead me to this solution can be found here: https://caddy.community/t/reverse-proxy-to-a-upstream-server-with-a-path-or-subfolder/15335
Combined with the existing handle_path mechanism that gives you rather flexible rewrite options.
Kind regards, Patrick