[MapProxy] mapproxy behind a reverse proxy and use of X-Script-Name

[Anne Blankert]

Hello,

Thanks for your reply.

On 21-3-2013 23:14, Milo van der Linden wrote:
>
> Hello Anne,
>
> It is pretty hard for mapproxy to guess your apache setup :-). I think 
> you are hoping this can be overrided somewhere within the 
> configuration, but my gut tells me that would introduce new issues 
> within mapproxy..
>
I do not (yet) understand why there would be a problem.

There are many good reasons to have a reverse proxy in front of 
services. One of these is that it can remove implementation and version 
specifics from a service URL. This is really important, especially for 
mapping services, because any future URL changes would require all 
clients to update the URL.

A reverse proxy behaves as any standard MapProxy client. The only 
difference is that it tells MapProxy through additional request headers 
that it is doing its requests on behalf of another client. These headers 
are X-Forwarded-Host, X-Forwarded-Proto and X-Script-Name. MapProxy has 
support for these additional headers.

I believe the support for X-Script-Name is not implemented as it should. 
The assumption seems to have been that a reverse proxy always maps to 
MapProxy (http://host/mapproxy) and not to individual MapProxy services 
(http://host/mapproxy/service, http://host/mapproxy/demo etc.)

Instead, I think the mapping should work like this:
externalhost/externalpath/externalservicename => 
internalhost/mapproxy/configname/mapproxyservicename
externalhost/externalpath/otherservicename => 
(other)internalholhost/mapproxy/(other)configname/othermapproxyservicename
etc.

For WMS services, the proxy-mapping problem only applies to the 
GetCapabilities functionality. Since the mapping is based on additional 
request-headers, this should not break any other MapProxy functionality?

I have been looking at the MapProxy source code, but it is still 
somewhat above my head. Is there a way to make the handling of 
X-Script-Name both backwards compatible and map to the service name? 
Could/should there be support for something like service_url in the yaml 
wms service configuration? Any other solution? Or maybe the current 
proxy-support should not be considered a problem at all?

Thanks,

Anne