Responding to a direct email response to my post here, let me clarify my setup.
I am using the Osimis docker image for Orthanc that comes with a number of plugins pre-installed and configured by way of environmental variables at the time of the Docker container launch.
Because I run multiple different Orthancs on the same docker host machine, I allocate a sub-URL to each using Apache for reverse proxy and a <Location /sub-URL/> configuration that assigns the sub-URL.
This approach has worked fine, likely because Orthanc internally was written to refer to itself internally with relative rather than absolute URLs.
Where this reverse proxy with a sub-URL can get into trouble is with web apps that were written using absolute URL paths, basically assuming the app is running on the top level main host URL.
I recently started looking at the Orthanc Explorer 2 plugin. I can make it work when I run the Orthanc at the top level host URL (ex. http://127.0.0.1:8042) but not if I redirect via Apache reverse proxy with to a sub-URL (ex. http://my.proxy/sub-URL ↔ http://127.0.0.1:8042/). Doing so generates a number of errors from basic 404 errors to javascript errors. The Orthanc (and the legacy explorer page) runs just fine behind the proxy, but the OE2 plugin does not.
Reminder: This is all within the context of the Osimis Docker image. I am not building OE2 myself, but using the image pre-built plugin.
My first guess was that the Osimis compilation of OE2 that they bundled into their Orthanc docker image assumes the Orthanc is running at the top level URL. So I have been digging into the Docker file.
Or, I simply am not sophisticated enough with my reverse proxy settings to get the plugin to behave on a sub-URL.
I have tried using the environmental variables to control the Docker container, including different settings for the OE2 root directory. I have the best (although still incomplete) response when I set the OE2 root to reflect my sub-URL. At least the 404 errors go away, but then the plugin crashes with javascript errors (undeclared variables, unexpected zero valued fields, etc.)
I have seen similar behavior before with other node/npm based apps. My intuition is that I will need to rebuild the OE2 node app myself with my sub-URL baked in. That, or I learn more sophisticated rewrite rules using Apache to fix the proxying back and forth.
I could post my current error messages and will if someone wants them. I don’t think they are that informative. At the moment, I would be happy to work out the kinks myself if I could get confirmation as to whether the OE2 app assumes it is running at the top level URL or not. Knowing that would give me a better idea how to tackle the problem I created for myself with sub-URL proxying.
I wonder if they consolidated that functionality into the main OE2 root parameter?
