QGIS server 3.x generates invalid schemaLocation for WMS 1.3.0 GetCapabilities request

[ShaunForbes]

The XML generated by the GetCapabilities request for WMS version 1.3.0 includes a xsi:schemaLocation attribute that is not valid, it appears to be missing the namespace for a schema extensions it includes.

xsi:schemaLocation="http://www.opengis.net/wms http://schemas.opengis.net/wms/1.3.0/capabilities_1_3_0.xsd http://www.opengis.net/sld http://schemas.opengis.net/sld/1.1.0/sld_capabilities.xsd http://qgis34.lan/qgis?MAP=/data/qgis/map_3_4.qgs&SERVICE=WMS&REQUEST=GetSchemaExtension"

You can see at the end the inclusion of the URL pointing back to the source QGIS server to retrieve the schema extensions content, but the URL is not prefixed by a namespace, which looking at the content of the URL looks like it should be http://www.qgis.org/wms.

So the schemaLocation should be:

xsi:schemaLocation="http://www.opengis.net/wms http://schemas.opengis.net/wms/1.3.0/capabilities_1_3_0.xsd http://www.opengis.net/sld http://schemas.opengis.net/sld/1.1.0/sld_capabilities.xsd http://www.qgis.org/wms http://qgis34.lan/qgis?MAP=/data/qgis/map_3_4.qgs&SERVICE=WMS&REQUEST=GetSchemaExtension"

The getCapabilities method in qgswmsgetcapabilities.cpp adds this schema location at line 220 with the following code:

schemaLocation += " " + hrefString + "SERVICE=WMS&REQUEST=GetSchemaExtension";

which should be (something like):

schemaLocation += " http://www.qgis.org/wms " + hrefString + "SERVICE=WMS&REQUEST=GetSchemaExtension";

Earlier code to add other schema location entries use QStringLiteral and QLatin1String to add the schema location entries so I'm not sure if the original code or the updated code above should also be using those when creating the schema location value.

Alternatively, this schema, if it is not supposed to be linked to a namespace, should be included in the xsi:noNamespaceSchemaLocation attribute rather than the xsi:schemaLocation attribute (but I don't think that is the case).

[elpaso]

@pblottiere do you remember why did you "Remove qgis address from schemaLocation" ?

[elpaso]

@pblottiere gentle ping

[pblottiere]

Hi @elpaso,

According to my explanation in the corresponding PR #8551, http://www.qgis.org/wms was returning a 404 error and OGC tests was failing due to this invalid URL.

At that time, I pinged Richard and he didn't know the origin of http://www.qgis.org/wms. The URL is valid again, but it returns nothing.

In my PR, I removed the QGIS adress from schemaLocation for the GetCapabilities document, but I didn't take care of the GetSchemaExtension request. So I propose to remove the address from this document too.

What do you think?

[pblottiere]

And sorry for the delay, I missed the first ping :).

[elpaso]

@pblottiere AFAIK a namespace is just a unique string identifier (usually an URI) but it does not need to be a valid URI even if it's in the form of an URI.

The current situation is that we are including a schema in xsi:schemaLocation without specifying its namespace, which is plain wrong.

We cannot drop our schema location because it contains the GetPrint & C. vendor extensions.

Can you try to revert that commit? I think that if the CITE test complains about a namespace identifier not being a valid URI it's a bug in the CITE test.

[pblottiere]

AFAIK a namespace is just a unique string identifier (usually an URI) but it does not need to be a valid URI even if it's in the form of an URI.

I think that if the CITE test complains about a namespace identifier not being a valid URI it's a bug in the CITE test.

FYI, the next issue was raised due to the invalid namespace URI from OGC tests: http://test.qgis.org/ogc_cite/wms_130/2018_11_29_06_00/report.html#bcba7976-dacb-4696-935e-357959cc2b82/d1e17334_1/d1e17409_1/d1e1362_1/d1e1436_1

And looking back, I think you're totally right, it seems to be a bug in the CITE tests. I'll try to reproduce the issue in order to open a bug report on https://github.com/opengeospatial/ets-wms13.

The current situation is that we are including a schema in xsi:schemaLocation without specifying its namespace, which is plain wrong.

Yes, you're right, my mistake...

Can you try to revert that commit?

Yes I think we can safely revert this commit, especially since http://www.qgis.org/wms is valid again. But I'd just like to check that everything is right with the certification before reverting the PR.

Moreover, we definitely should know who is behind http://www.qgis.org/wms :).

[ShaunForbes]

Hey,

I'm sure you already know this, I just wanted to point out just in case, but just reversing the original commit as it was will still generate an invalid schemaLocation if the Inspire stuff is active, since for some reason the Inspire related entries were placed right in the middle of the QGis WMS schema entry (I couldn't locate exactly when this happened, I think it might have been there all along after a major restructuring).
The namespace should be added after the Inspire entries and not before them as was the case in the code before ce0d76a.

[pblottiere]

Hi @ShaunForbes,

I'm sure you already know this, I just wanted to point out just in case, but just reversing the original commit as it was will still generate an invalid schemaLocation if the Inspire stuff is active, since for some reason the Inspire related entries were placed right in the middle of the QGis WMS schema entry

No, I didn't noticed that. Does the next xsi:schemaLocation looks good to you (just in case I missed something else)?

xsi:schemaLocation="
http://www.opengis.net/wms http://schemas.opengis.net/wms/1.3.0/capabilities_1_3_0.xsd 
http://www.opengis.net/sld http://schemas.opengis.net/sld/1.1.0/sld_capabilities.xsd 
http://inspire.ec.europa.eu/schemas/inspire_vs/1.0 http://inspire.ec.europa.eu/schemas/inspire_vs/1.0/inspire_vs.xsd 
http://www.qgis.org/wms http://localhost/qgisserver?MAP=/home/pblottiere/schema.qgz&SERVICE=WMS&REQUEST=GetSchemaExtension
"

And thanks for your inputs, it's very valuable 👍

[ShaunForbes]

Hey @pblottiere,

That looks like what I'd expect to see (if the Inspire stuff was active, which presumably it isn't for me since that schema isn't included in my capabilities docs).

Cheers