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)

[joao-jtjsoftware]

I reproduced this and have a tested implementation that distinguishes an absent Accept header from an unsupported one.

Based on the discussion above, I kept the existing behaviour as the default and made strict negotiation opt-in through:

server:
  api_rules:
    strict_content_negotiation: true

With the option enabled:

• an Accept header with no supported representation returns 406 Not Acceptable;
• / uses the default representation;
• type wildcards such as image/* select the first compatible representation;
• an invalid ?f= value continues to return 400 InvalidParameterValue.

With the option omitted or set to false, pygeoapi retains its current fallback behaviour. The implementation covers Flask, Starlette and Django, and includes configuration schema, documentation and tests.

@tomkralidis, does this opt-in approach match the direction you had in mind? I am opening a draft PR so the implementation can be reviewed without treating the behaviour as settled.

[francescoingv]

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.