Repository navigation
return error if unsupported mimetype is requested #2374
Description
Description
why does pygeoapi return geojson if i send an accept header application/vnd.lala, expected is an error, status 406 requested mimetype not supported, exception could be if no accept header is sent, to return a json or html type encoding.
Steps to Reproduce
send header accept:application/vnd.lala to https://demo.pygeoapi.io/master/collections/dutch_castles/items?crs=http://www.opengis.net/def/crs/EPSG/0/28992
Expected behavior
error message requested mimetype not supported
Activity
[-]return error if unupported mimetype is requested[/-][+]return error if unsupported mimetype is requested[/+]webb-ben commentedon Jun 26, 2026
perhaps it is worth having this as a configuration option? Should the API not use the default mimetype if no matching mimes?
mikemahoney218-usgs commentedon Jun 26, 2026
The HTTP standard says:
And then later in Section 12 (Content Negotiation)
As such, my read is that pygeoapi's behavior here is in line with standards, and this becomes a question of preference. Personally I prefer sending the default representation, as I view that as being more likely to meet the client's needs, but I could see an argument for a configuration option for folks who want stricter behavior.
pvgenuchten commentedon Jun 26, 2026
OGC indicates in table 2 a lists the http status codes, for 406 ogc indicates:
Content negotiation failed. For example, the Accept header submitted in the request did not support any of the media types supported by the server for the requested resource.this is however written from a client perspective (client should be prepared to receive these status codes). Beyond that the document refers to IETF RFC 7231.Agree with @mikemahoney218-usgs, rfc7231 does not require servers to return 406 if accept header does not include a supported encoding.
One would however expect similar behaviour between accept header and ?f=, and in pygeoapi ?f= always throws an error if a non existing encoding is requested, so maybe i should reframe the issue, ?f=xxx should also return a default encoding if the requested encoding is not supported for that operation... Or just close the issue, because ?f= is not part of any standard...
webb-ben commentedon Jun 26, 2026
I think Accept headers and f= query argument are not equivalent. The query argument overrides ALL content negotiation. The Accept header lists expected client types.
Will note that pygeoapi does content negotiation against 'application/json'. Which would mean a request like this would throw an error:
This could be addressed by adding incorporating a GeoJSON mimetype to recognized formats but it would be a significant change the existing API to return an error if any accept header is not found when the format override query argument is not used.
We would also need to implement parsing for the mimetype / to then return the server default.
If this is implemented +1 towards a deployment configuration to return the default content instead of an error
webb-ben commentedon Jun 26, 2026
We would also want to make sure this is functional with the google crawler (#901)
francescoingv commentedon Aug 1, 2026
I am very interested in support to content negotiation about Processors.
It should be possible a client will request a result by content negotiation, specifically when only one output is requested.
But the logic should be within the Processor, where the metadata on the possible outputs is defined. Therefore in that case, the Processor, not the API, should receive the Accept header, and prepare the answer (possibly the error code).
Currently I cannot make tests, but I wonder if this aspect was, or will be, considered in @joao-jtjsoftware proposed solution.