Adding WMS imagery doesn't work properly for https enabled sites

[SanderH]

What steps will reproduce the problem?

1. In the menu click Imagery -> Imagery preferences
2. Click to add WMS
3. Enter a https server, optionally explicitly setting the port to :443

What is the expected result?

The basic service URL is used unaltered in the Verify generated WMS URL box.

What happens instead?

In the Verify generated WMS URL box, https is changed to http and port 80 is wrongly added and if the port 443 was used it's also reset to port 80. This makes the WMS fail, and users having to correct the service url.

Please provide any additional information below. Attach a screenshot if possible.

I have created a WMS service and configured it for https. JOSM can use the WMS, but configuring it via the 'Add Imagery URL' dialog is a bit troublesome.

I don't (yet) want to share my WMS publicly, but if you want, I can provide you with it via e-mail.

URL:http://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2016-08-11 21:54:24 +0200 (Thu, 11 Aug 2016)
Build-Date:2016-08-11 22:36:05
Revision:10786
Relative:URL: ^/trunk

Identification: JOSM/1.5 (10786 en) Windows 10 64-Bit
Memory Usage: 2015 MB / 2015 MB (1136 MB allocated, but free)
Java version: 1.8.0_102-b14, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
VM arguments: [-Djava.security.manager, -Djava.security.policy=file:<java.home>\lib\security\javaws.policy, -DtrustProxy=true, -Djnlpx.home=<java.home>\bin, -Djnlpx.origFilenameArg=%UserProfile%\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\56\1ee8cfb8-5ee29e1d, -Djnlpx.remove=false, -Djava.util.Arrays.useLegacyMergeSort=true, -Djnlpx.splashport=10071, -Djnlp.application.href=https://josm.openstreetmap.de/download/josm.jnlp, -Djnlpx.jvm=<java.home>\bin\javaw.exe, -Djnlpx.vmargs=LURqYXZhLnV0aWwuQXJyYXlzLnVzZUxlZ2FjeU1lcmdlU29ydD10cnVlAC1Eam5scC5hcHBsaWNhdGlvbi5ocmVmPWh0dHBzOi8vam9zbS5vcGVuc3RyZWV0bWFwLmRlL2Rvd25sb2FkL2pvc20uam5scAA=]
Dataset consistency test: No problems found

[SanderH]

screenshot of the dialog

[Klumbumbus]

I also noticed, that http was generated while only https worked when I added Maps/Germany#Erlangenaerialimagery20165.0cm.
Its wms link is ​https://secure.erlangen.de/arcgiser/services/Luftbild2016/MapServer/WMSServer?SERVICE=WMS&REQUEST=GetCapabilities

[wiktorn]

Capability/GetMap/DCPType/HTTP/GET points to http://secure.erlangen.de/arcgiser/services/Luftbild2016/MapServer/WmsServer? which uses HTTP.

It looks like the problem lies on the GetCapabilities document, that it still points to http URL's

[SanderH]

Looked a bit further and indeed the geoserver instance returned ​http://someserver:80, although it is running on the default port 8080.
I'm using Nginx with Let's Encrypt certificate to make the Geoserver available as https using a reverse proxy configuration.
By setting the GeoServer - Global Settings - OGC Services - Proxy Base URL to the url is known outside, JOSM works properly now.

wiktorn, thanks for the comment for putting me into the right direction that the geoserver itself wasn't telling what JOSM needed.

Nevertheless, for services that support multiple access url's, it seems strange that only a single url can work at the same time as I don't think that the capabilities xml supports returning multiple url's. In which case, adding an option to retain the base service url may help in those cases. I don't know how often it would occur that both http and https are supported and is such an improvement is worth the effort.

[wiktorn]

I checked the specification and WMS standard allows only for one URL for GetMap operation using HTTP GET. Which is quite reasonable, because choosing the URL is only additional burden for end user with no benefit.

If you have your service exposed on multiple URL's and you want the maps to be accessed by different URL's, then you need return different GetCapabilities document based on how the user accessed this document.

What I do like with current solution is that I can save GetCapabilities document locally (and do some tweaks) and it will still point to the remote server.