Parameters (the bits after a semicolon) are not currently respected for media type lookups; instead, we only look for charset explicitly in the Content-Type header and apply that for text/* types, and strip all other the parameters entirely (are there any that are relevant to parsing, or do we just need to incorporate this into a general-to-specific matching algorithm)?
However this won't work out for non-body encodings, such as headers or querystrings, where the media type would have to be included directly in the property name under "content", where we ignore parameters entirely (OAS parameters: headers, querystrings etc).
We need to more strictly follow the rules in RFC9110 8.3.1 for media-type parsing.
It also looks like some bits of the 3.2 spec, and the OAD schema, need to be amended also (not just for clarity, but I see at least one error).
see also OAI/OpenAPI-Specification#2342
also see my notes file TODO-media-types for more extensive treatment.
Parameters (the bits after a semicolon) are not currently respected for media type lookups; instead, we only look for charset explicitly in the Content-Type header and apply that for text/* types, and strip all other the parameters entirely (are there any that are relevant to parsing, or do we just need to incorporate this into a general-to-specific matching algorithm)?
However this won't work out for non-body encodings, such as headers or querystrings, where the media type would have to be included directly in the property name under "content", where we ignore parameters entirely (OAS parameters: headers, querystrings etc).
We need to more strictly follow the rules in RFC9110 8.3.1 for media-type parsing.
It also looks like some bits of the 3.2 spec, and the OAD schema, need to be amended also (not just for clarity, but I see at least one error).
see also OAI/OpenAPI-Specification#2342
also see my notes file TODO-media-types for more extensive treatment.