Steve Bennett
Steve Bennett
> We should also consider whether it makes sense to shift to a more sensible error code. You mean, detect the error (inspecting the XML for an error message), and...
Just pointing out the obvious: if there are Geoservers with CORS enabled, we'll still have to proxy them.
well, if we want the benefit of proper error codes in TerriaJS, that is.
Hmm, alternatively, "foo" could mean "all ports on foo", and "foo:80" could mean "only port 80". What would the downside of this be?
Hmm, good thoughts. Another option that's just occurred to me would be to whitelist on the basis of the non-host part of the URL. For instance, whitelist any URL containing...
ah. yes. Oops. Is this happening in prod somewhere?
And this one ``` { "name": "Topography", "type": "esri-mapServer", "url": "http://services.thelist.tas.gov.au/arcgis/rest/services/Basemaps/Topographic/ImageServer", "legendUrl": "http://services.thelist.tas.gov.au/arcgis/rest/services/Basemaps/Topographic/ImageServer/legend", "rectangle": [ 140, -44, 150, -40 ] } ```
Mostly fixed by #70 .
Yeah I know. It's an output from turf.polygonize. it's hard to prevent stuff like that happening when you're processing third party data.
Yeah, I considered trying to pass back the error message more directly, but that also seemed messy. I would have liked to create a custom exception class, but that seems...