I’m a little surprised that ImageServer has anything to do with this… I’m not super-familiar with it but I’m not aware of it really changing what the “normal” file URLs are at all.
It sounds like you’re putting a reverse proxy in between clients and your Omeka server… one possible simple solution may be to configure IIS to pass through the Host header to the Omeka backend server. I don’t know exactly how you do that with IIS but I believe there’s a setting for it.
Thank you. The IIS Host header solution might be feasible. One thing I did like about the URL rewrite solution was that Omeka was showing up under our domain (so, https://ourdomain.com/omeka/etc) and I think under the host header, I will have to have a subdomain (so, http://subdomain.ourdomain.com/etc and I guess also supply an SSL certificate on the server with Omeka).
When you say “I’m a little surprised …” do you think maybe something else is going on here?
My mention of surprise was just that I don’t think Image Server affects “normal” links to the files, and that this kind of proxy situation you’re describing is capable of causing these problems on its own.
I’m not sure the proxy and Host passthrough would require you to use a subdomain, but I’m not really up on IIS config. Having the path that proxies not match the path on the origin server could cause similar linking issues to what you’re seeing now, but you could just move the Omeka install on the origin server to a matching path to avoid that, I’d think.
