Hi Jukka, With regards to:
> • 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 > Do you have a reference to why this should be HTTP 200 (Success)? If the bbox parameter is invalid then it is treated as other bad parameter settings and return HTTP 400 e.g. https://demo.mapserver.org/cgi-bin/mapserv/localdemo/ogcapi/collections/countries/items?f=html&limit=10&offset=a The spec also refers to HTTP 400 - https://docs.ogc.org/is/17-069r3/17-069r3.html#query_parameters Or have I misunderstood the issue? Seth -- 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
