Content type sniffing priority (3.3+)

[hudlow]

This is somewhat related to #3306. I have a use case where I want the API definition itself to be clear that the server will sniff one or more content types per RFC 9110 §8.3:

A sender that generates a message containing content SHOULD generate a Content-Type header field in that message unless the intended media type of the enclosed representation is unknown to the sender. If a Content-Type header field is not present, the recipient MAY either assume a media type of "application/octet-stream" or examine the data to determine its type.

Notably, I don't want to imply that sniffing will occur except when a client does not provide the content-type header.

The precise use case for me here is creating a mock server that matches the implemented sniffing behavior which allows content-type for request messages to be omitted for supported content types.

One way I can envision this being achieved is by allowing a sniffPriority keyword to the Media Type Object. This would serve to indicate in what order a well-behaved server (or client?) implementation should attempt to sniff the content type.

For my use case, I primarily care about simply indicating that if a client does not supply content-type then the server will still attempt to parse the content as JSON, but I can easily imagine a scenario where this would be used to indicate (for example) that if a client doesn't supply content-type, a server will try to sniff application/json-patch+json before it tries to sniff application/merge-patch+json given the the latter is a superset of the former.

I can also imagine that, in the same way, in cases where an API definition is being used to described an existing server implementation which doesn't supply a content type, sniffPriority could suggest to client the order in which they should sniff the content to match it to handling specific to a schema. (Obviously I wouldn't advocate a greenfield API ever omit content-type.)

This suggestion is a bit tentative because it's a bit unclear to me whether the complexity of its addition to OpenAPI is disproportionate to the demand, whether it's really the right approach, and whether it is actually reasonable to encourage sniffing in any scenario.

But I would be curious to see more discussion (or links to prior discussion I haven't been able to find) when time permits.

[handrews]

@hudlow I'm extremely reluctant to add features to the OAS that either contradicts the HTTP specification or actively enables practices that it acknowledges but discourages. In particular, the "Some user agents" in RFC9110 §8.3 clearly refers to web browsers which have a long-standing practice of sniffing. But sniffing is not well-established for APIs AFAICT. And a concept like "sniff priority" seems like a new invention.

At most, this is something that should be explored with x- extensions. I would only consider it for the specification if an x- approach sees substantial adoption.

[handrews]

@hudlow BTW if you think I've mischaracterized things with respect to what RFC9110 says here, please do let me know.
I'm not inherently against mentioning sniffing (we have to allow for it for some weird multipart cases), this just seems like circumventing the RFC's intentions.

[handrews]

Tagging with "registries" to encourage consideration of an extension prior to considering spec changes.