Undesirable functionality: WMSLayer doesn't use original url in GetMap (and other requests)

D_R_

Good afternoon,

I have same problem somebody in this topic -> https://community.esri.com/t5/arcgis-javascript-maps-sdk-questions/jsapi-4-requesting-wrong-url-when-loading-wms-from/td-p/1058917 had.

I create a simple WMSLayer({url: url}) and under the hood SDK replaces that url with some other url which is retrieved from WMS's GetCapabilities.

ArcGIS API for JavaScript (legacy) 3.X didn't have this problem. I see this new functionality as a regression..

What are your thoughts about it? Any plans to improve WMS constructor?

Theoretically I can use esriConfig.request.interceptors and change url in "before" method, but the problem is that you have to hardcode url you need to replace. I mean just look at https://community.esri.com/t5/arcgis-javascript-maps-sdk-questions/jsapi-4-requesting-wrong-url-when-loading-wms-from/td-p/1058917 -> It is bad practice to hardcode host and url as was done in that case... And in my case I have big amount of WMS layers...

Could you improve your SDK by adding interceptor to layer's constructor maybe so that it acts on current layer only?? I think that should help in such cases..

 

JoelBennett

Ok, there's actually a significant difference between what's going on in this case versus what was going on in the other thread.  Before getting into the difference, just a brief description of things you may already know (for the sake of clarity).  When creating a WMSLayer, the layer sends a GetCapabilities request to get information about the service it will be accessing.  The response is an XML document, and embedded within is the URLs the application should use when making calls to GetMap and/or GetFeatureInfo.

In the case of the other thread, the URL for GetMap was a relative URL.  Since the hostname was not included, the SDK likely assumed it was the same host as the URL in the browser's address bar.  Since the host for the page in the browser was not the same as the host for the WMS server, this gave the unexpected results described in that thread.  Personally, I think the SDK should be able to handle relative URLs better, using the hostname passed into the constructor instead, but those kinds of design decisions are the SDK development team's prerogative.

However, this is not what's happening in your case.  Instead, the GetCapabilities response has absolute URLs, and the GetMap URL is the hard-coded value "http://46.255.211.67:85/geoserver/Etnografinis_zemelapis/ows?SERVICE=WMS&".  Therefore, the SDK is working exactly as it should by sending the GetMap requests to that URL, because that's what the service told it to do.

There's really only two ways to deal with this.  (1) Contact the WMS service's administrator, and request that they reconfigure the service.  It seems unlikely to me that's going to work though.  Instead (2) you will have to do some replacing on the client-side...there's just no way around it.  You could use a RequestInterceptor like the other thread shows, or you could fix the URLs on your layer object by doing something like the following:

 

const layer = new WMSLayer({
  url: "https://www.geoportal.lt/mapproxy/etnografinis_zemelapis/wms"
});

layer.load().then(() => {
  layer.featureInfoUrl = layer.featureInfoUrl.replace("http://46.255.211.67:85/geoserver/", "https://www.geoportal.lt/mapproxy/");
  layer.mapUrl = layer.mapUrl.replace("http://46.255.211.67:85/geoserver/", "https://www.geoportal.lt/mapproxy/");
});