return error if unsupported mimetype is requested

[pvgenuchten]

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

[webb-ben]

perhaps it is worth having this as a configuration option? Should the API not use the default mimetype if no matching mimes?

[mikemahoney218-usgs]

The HTTP standard says:

15.5.7. 406 Not Acceptable
The 406 (Not Acceptable) status code indicates that the target resource does not have a current representation that would be acceptable to the user agent, according to the proactive negotiation header fields received in the request (Section 12.1), and the server is unwilling to supply a default representation.

And then later in Section 12 (Content Negotiation)

A user agent cannot rely on proactive negotiation preferences being consistently honored, since the origin server might not implement proactive negotiation for the requested resource or might decide that sending a response that doesn't conform to the user agent's preferences is better than sending a 406 (Not Acceptable) response.

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]

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]

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:

curl \
  -H 'Accept: application/geo+json' \
  https://example.org/collections/buildings/items

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]

We would also want to make sure this is functional with the google crawler (#901)