- edited description
Redirect Url is not updated to WMS Url
If you use a rewrite rule on a server the new url becomes not updated on the WMS Url text field.
This should behave same as a web browser doing. e.g. http://mss-stage.icg.kfa-juelich.de/demo becomes redirected to http://mss-stage.icg.kfa-juelich.de:81/demo
get map request recrognizes the change
Comments (12)
-
reporter -
reporter - marked as minor
-
reporter - changed milestone to 1.4.0
-
I just had a look at this issue and this is not simple. The XML capability document specifies (at least) two URLs for Get and Post actions. This need not be related to the URL where the XML is located. Certainly it may look much more complicated. While we could overwrite the combobox with the value of the Get action, this might be confusing and could cause subsequent calls to getCapability to fail.
Instead, I propose to change the check for consistency between the combobox and the WMS to check that the URL is still the same that was used to retrieve the XML document. Secondly, it might be more elegant to disable the getmap button if the combobox value was changed by the user.
-
reporter This is something different I think.
We need a way to show the changed value in the wms url interface.
-
Okay, there are at least two different types of problem. a) The server is allowed to specify an arbitrary URL for the getmap GET request that is not related to the capability URL b) The server may redirect either the capability or the getmap calls to some other URL.
From a server perspective, it does not make sense to first specify an URL in the capability document and then redirect that call. Further, the UI has currently no concept of the actual getmap URL and needn't have.
But with respect to the capability document, we may exchange the specified URL with the redirected URL.That redirection/url handling is so far only handled rather deep OWS internally
One could handle this by 1) patching OWSlib to compare the requested and retrieved URL, extract the changed base_url and overwrite the original url member with the redirected one. 2) overwriting the combobox item with the new url
This is feasible, I see however a couple of things where this could go awry... Still we might go for it. The question is, whether the benefits of this change really outweigh the risks.
-
reporter - changed milestone to 1.5.0
-
reporter - changed milestone to 1.4.0
This is not a blocker. If there is no simple solution for 1.4 we postpone this to a later release.
-
reporter -
assigned issue to
-
assigned issue to
-
reporter Until this is not fixed none of the url shortener could be used.
-
reporter - changed status to resolved
WMS Url gets updated to redirected Url, fixes
#135→ <<cset 4621db72d399>>
-
reporter Merged in ReimarBauer/mss/redirect (pull request #282)
WMS Url gets updated to redirected Url, fixes
#135→ <<cset 443ddc8fab64>>
- Log in to comment