While working on SCIM v2 support within nexus, @jmpesp and I ran into an issue with the request bodies coming from identity providers such as Okta. It turns out SCIM v2 is using a content-type of application/scim+json as defined in RFC 7644 Section 8.1.

Dropshot currently chokes on this because the built-in extractors for the request body have a whitelist of mime types defined here:

Which is later checked here:

There are a few paths forward discussed on the control plane huddle:

• Implement a custom extractor for your json like alias
• Simply add the scim+json type to the defined enum
• Maintain a list of json mime type aliases and expose them via the same enum
• Another approach not yet realized...

The returned body out of dropshot can be easily be worked around at this time as the Response type lets you set header value yourself.