Request Content-Type matching underspecified?

[openreply-dleinhaeuser]

I have not been able to find any documentation that describes with sufficient detail how the Content-Type header of a request is matched against the entries of the Request Body Object.
In particular there is not a word lost on how to handle media ranges in the Request Body Object that have parameters, or if parameters are even supported there.
We had to learn that different OpenAPI validator implementations can have widely diverging behavior in this area.

Behaviors we have encountered include but are not limited to:

• matching all specified parameters and their values with the parameters of the request content type
• matching all specified parameters but not allowing extra parameters (many clients automatically add charset)
• matching all specified parameters but also requiring the parameters to be specified in the same order as in the OpenAPI document (probably a bug)
• matching all specified parameters but being strangely specific about whitespace (very likely a bug)
• doing what type-is does (ignore parameters on request content type, break if there are parameters in the Request Body Object)
• doing a simple string comparison between request Content-Type header and Request Body Object entry (definitely a bug)

This divergence prompted me to look up what the semantics are supposed to be, but I have been unable to find anything in the OpenAPI spec or in the commonly cited RFCs that provides clarity here.

Is there a definitive way this should be implemented? Is this unspecified on purpose?

I would be grateful if you could help me gain some clarity here.

[hkosova]

Related: #2342

[karenetheridge]

In my implementation I strip everything after ; from the media-type before performing matching against the OAD; I saw no other option given that parameters can appear in wildly different orders and most of them are not even relevant to the core purpose of finding a matching schema to validate against.

See also #2342 where I say more.