Accept a top-level prefix for a reverse-proxy situation

[bgstack15]

Would you please consider modifying the application to pull (mainly image) assets from a manually-configured top-level prefix, e.g., "/seven-wonders/"? I shared an Apache httpd config that demonstrates a reverse-proxy for "www.example.com/seven-wonders/" and I had to rewrite the image requests where the client requests just "/images/cards/altar.png."

If the app could consume an http header of "X-Forwarded-Prefix" or at least be manually configurable at server run-time, it would make a reverse-proxy one step easier!

[joffrey-bion]

Hi, thanks for opening this issue. Do I understand correctly that you would like the images root path to be configurable? That should indeed be possible. Currently the images are all under the same root path (albeit not configurable).

That said I'm not sure I understand the end game. Is the goal to configure only the asset paths or also the websocket endpoint and things like this?

[joffrey-bion]

Ah I think I understand the problem. The app currently generates URLs to assets using hardcoded paths that don't respect X-Forwarded-Prefix, and thus if you configure a reverse-proxy serving seven-wonders under some path, every image URL will be broken from outside. I will try to solve this once I'm done with the frontend migration to the new Kotlin/React

This approach could help: https://tomgregory.com/spring-boot-behind-load-balancer-using-x-forwarded-headers/

[bgstack15]

I only know how to configure Apache to r-p the websocket with the separate statement, so that won't go away as far as I can guess. Just if the app could emit prefixed asset paths, that would facilitate serving the app through a reverse-proxy and would eliminate the need of the RewriteRule. So basically just the images need to be set either with a setting (at the docker container run time) or maybe by consuming the prefix header.