Thanks Jukka for testing with the validator. The extra parameters issue has been discussed before - a major issue is that all cookie parameters are seen as request parameters. See [1] and [2]. I'm not sure if it has been addressed in pygeoapi which is the reference implementation. MapServer also uses parameters for runtime-subsitution so enforcing no extra parameters will break a lot of MapServer workflows.
I think it was suggested adding a "strict" WEB METADATA item that would return a 400 error when extra parameters were encountered - this would allow tests to pass fo a particular server. What is the service meant to do with invalid geometry such as that polygon - throw an error? It would be good to open the other items as issues on GitHub to fix. Seth [1] https://lists.osgeo.org/pipermail/mapserver-dev/2021-September/016620.html [2] https://github.com/MapServer/MapServer/pull/6400#issuecomment-936458600 -- web:https://geographika.net & https://mapserverstudio.net twitter: @geographika On Wed, Oct 18, 2023, at 9:21 AM, Rahkonen Jukka via MapServer-dev wrote: > Hi, > > I used the OGC Teamengine for testing our OGCFeat demo at > https://demo.mapserver.org/cgi-bin/mapserv/localdemo/ogcapi. > The validator found a few issues: > > • Wrong http status code: returns 400, should be 200 > https://demo.mapserver.org/cgi-bin/mapserv/localdemo/ogcapi/collections/countries/items?bbox=177.0000000%2C65.0000000%2C-177.0000000%2C70.0000000 > > • Some tests fail because the service returns invalid geometries. Mapserver > actually works right but because of invalid topology the validator fails. For > example a geometry of the France multipolygon, somewhere near the French > Guiana is invalid due to duplicated vertices at POINT (-52.939657 2.124858). > The BBOX in the test was BBOX= -1.5000000,50.0000000,1.5000000,53.0000000. > There are other similar geometries showing self-intersection. > • If query contains an unknown parameter then our server sends data, but it > should error out and send a http 400 error. > Test request: > https://demo.mapserver.org/cgi-bin/mapserv/localdemo/ogcapi/collections/ocean-labels/items?unknownQueryParameter13515=1 > > • The Content-Crs header is missing when the request is using the default > crs. Test query: > https://demo.mapserver.org/cgi-bin/mapserv/localdemo/ogcapi/collections/ocean/items?f=json > I have looked at the extra parameter thing from the standard and from the > discussions in the OGC GitHub. Notes from the research: > > The server SHALL respond with a response with the status code `400`, if the > request URI includes a query parameter that is not specified in the API > definition. For omitting unknown “vendor specific” parameters is must be > defined in the API as > > in: query > > name: vendorSpecificParameters > > schema: > > type: object > > additionalProperties: true > > style: form > > If a server wants to support vendor specific parameters, these have to be > explicitly declared in the API definition. If OpenAPI is used to represent > the API definition, a capability exists to allow additional parameters > without explicitly declaring them. That is, parameters that have not been > explicitly specified in the API definition for the operation will be ignored. > > With minor changes Mapserver could get the certificates for OGC API Features > Core and CRS. But I wonder what to do with the demo service. The server that > is used for the CITE tests must be available online. We could try to fix the > existing Natural Earth data and service so that it sends topologically valid > geometries. Another option would be to set up another service instance for > CITE tests with some known valid datasets. > > -Jukka Rahkonen- > _______________________________________________ > MapServer-dev mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/mapserver-dev >
_______________________________________________ MapServer-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/mapserver-dev
