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.
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 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.