Dealing with "relaxed" implementations of services regarding request parameters

[thijsbrentjens]

Several WMS and WFS implementations are relaxed towards required request parameters. For example, if the endpoint is a WMS, the service returns a Capabilities doc even if the required service parameter is not provided. Take for example: a) https://geodata.nationaalgeoregister.nl/cbsprovincies/wms?&request=GetCapabilities and b) https://geodata.nationaalgeoregister.nl/cbsprovincies/wms?&request=GetCapabilities&service=WMS

The service returns a Capabilities doc for both. Which makes sense from a user's perspective. This is done for other types of requests. For example for GetMap if a style parameter is missing, the service falls back to the default style. But the OGC specs require that the service parameter (or style for the other example) is provided.

The reference validator has checks that test on missing required parameters and fails the tests if services are relaxed towards missing required parameters (that are strictly not necessary for processing sometimes). From a specification perspective, this is correct. But service providers could feel this as a bit of "administrative" error only. So for discussion: should the reference validator tests this strictly on required parameters? Or should it be more relaxed too?

[inakidiazdecerio]

Dear @thijsbrentjens,

Thank you again.

We will include it for discussion in next subgoup meeting.

Regards.

[josemasensio]

Dear @thijsbrentjens,

What is happening here is that, the validator only takes the endpoint. The necessary parameters are added for each request in the test.

We are working on the way to validate the URL so that it's the same for all services (WFS, WMS and WMTS).

We will come back to you when the improvements are ready.

Best regards.

[thijsbrentjens]

Hi, could you please give an update on the status of this issue? Thanks in advance :).

[carlospzurita]

Dear @thijsbrentjens We relaxed the detection of test object types for WFS, WMS and WMTS, as solved in the ETF repository https://github.com/etf-validator/etf-webapp/issues/195. The valid objects can be detected if any of this conditions are met:

1. URI contains /wfs /wms or /wmts followed by ?
2. Parameters for for request service and version
3. Capabilities is returned by the endpoint and contains the correct label and namespace for the correspondent service

Anyway, this tests are only used to determine if the object provided is the correct kind, and is not reflected in the validation. All compulsory parameters will be tested by the ETS,

This fix is already present on https://inspire.ec.europa.eu/validator

WCS, SOS and CSW are left to solved, and have to be included on the ETF source code before deploying it on the INSPIRE validator.

[arbakker]

@carlospzurita very convenient that the detection of test object types is improved!

But my understanding of the issue by @thijsbrentjens is that it concerns the validation check that a WMS service should return a service exception when a GetCapabilities document is requested without the mandatory service parameter and he raises the question if the validator should be this strict.

Here is a WMS service that fails because of this requirement:

[JLSchaap]

@carlospzurita Can we expect that the validator is less strict in autumn 2021 as @arbakker proposes. (e.g. Is it possible to change this assertion to a warning?)

[dperezBM]

Dear all,

By the moment the validator will continue as it is on staging instance.

Best regards.

[dperezBM]

Dear all,

Since this issue had no interaction time ago, we decided to close it. Please feel free to open a new one if needed.

Thank you and best regards.

[JLSchaap]

@dperezBM I understand that the proposal to make the validator less strict is not implemented / rejected. Please reconsider this proposal in a subgroup meeting, in my opinion implementing this "administrative" rules does not improve the acceptance of Inspire validation and the usability of Inspire services.

[fabiovinci]

Dear @thijsbrentjens and @arbakker,

Since the WMS provided as an example are no longer working, can you provide new ones?

Thanks

[thijsbrentjens]

@fabiovinci I'm not involved directly anymore, hope that @arbakker can help :)

[arbakker]

@fabiovinci sorry I missed the notification of the mention. Here is a different service that returns a capabilities doc regardless of whether service=WMS request parameter is supplied:

• https://geodata.nationaalgeoregister.nl/publiekrechtelijkebeperking/wms?request=GetCapabilities
• https://geodata.nationaalgeoregister.nl/publiekrechtelijkebeperking/wms?request=GetCapabilities&service=WMS

We are in the proces of migrating our (GeoServer based) services to a different application stack, which gives us more control over the behaviour of the services. The above service still needs to be migrated, but will be available for at least another six months (so hope the issue is resolved before that :))