Thanks for the feedback Jukka. If I understand correctly, we are using OpenAPI, and so we are free to use any additional parameters? There is an open PR from Tom which adds this to the API definition: https://github.com/MapServer/MapServer/pull/7295
-- web:https://geographika.net & https://mapserverstudio.net mastodon: @[email protected] On Tue, Sep 30, 2025, at 1:23 PM, Rahkonen Jukka wrote: > Hi Seth, > > The OGC API Features standard has also some considerations about vendor > parameters > https://docs.ogc.org/is/17-069r4/17-069r4.html#query_parameters. I do > not know how to interpret the standard in this context but I believe > that it limits how much we can fiddle with the request URLs. I > recommend reading the whole paragraph but here is an excerpt: > > 7.6. Unknown or invalid query parameters > Requirement 8 > /req/core/query-param-unknown > > A > 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. > 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. > OpenAPI schema for additional "free-form" query parameters > in: query > name: vendorSpecificParameters > schema: > type: object > additionalProperties: true > style: form > > -Jukka Rahkonen- > > ________________________________________ > Lähettäjä: MapServer-dev käyttäjän Seth G via MapServer-dev puolesta > Lähetetty: Tiistai 30. syyskuuta 2025 12.31 > Vastaanottaja: MapServer Devs > Aihe: [MapServer-dev] Handling additional parameters in OGC Features API URLs > > > Hi devs, > > We've been discussing at the OSGeo codesprint how to handle extra > parameters when working with the OGC Features API. The issue is that > additional parameters, such as a security token, are not persisted to > the URLs constructed by MapServer. For example, a user might request: > > https://demo.mapserver.org/cgi-bin/mapserv/localdemo/ogcapi/collections/?f=json&token=98127319283 > > However, MapServer will return a JSON response with URLs like: > > "links": [ > {"href": > "https://demo.mapserver.org/cgi-bin/mapserv/localdemo/ogcapi/collections/ocean?f=json"} > ] > > Client applications can append extra parameters with every request, but > this is not always possible, for example when using ArcGIS Pro or QGIS. > > MapServer already supports adding parameters for WxS services using > Runtime Substitution, since all WEB METADATA values can accept > parameters. For example, the ows_onlineresource returned in a > GetCapabilities response can include URLs with tokens: > > "ows_onlineresource" > "http://my.host.com/cgi-bin/mapserv?map=/path/to/your-mapfile.map&%25TOKEN%25"; > > OGC Features URLs, however, are constructed in code by building paths > and then appending querystring parameters, so runtime substitution > cannot be used here. While HTML templates can be modified to include > additional parameters, this does not affect URLs returned in f=json > responses and updating all templates is time-consuming: > > {"href", api_root + "/collections/" + std::string(id_encoded) + "?f=json"} > > A proposed solution is to add a new METADATA item to allow extra > parameters to be appended to these URLs: > > "ows_extraparams" "token=%TOKEN%&userid=%USER_ID%" > > - This would use the same Runtime Substitution approach as other > METADATA items. > - Mapfile authors would be responsible for adding VALIDATION blocks for > the parameters. > - All URL construction in mapogcapi.cpp would be updated to append > extra_parameters to the end of URLs, handling edge cases such as ending > ampersands or empty strings: > {"href", api_root + "/collections/" + std::string(id_encoded) + > "?f=json" + extra_parameters} > > As with other METADATA items, LAYER-level metadata would take > precedence over WEB-level metadata. This would allow collection-level > parameters to be supported when required. > > Thoughts / comments welcome, > > Seth > > -- > web:https://geographika.net/ & https://mapserverstudio.net/ > mastodon: @[email protected] > _______________________________________________ > 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
