.Net: New Feature: Supporting additional content-type headers / media types for api calls.

[beyondszine]

---

name: Feature request
about: Supporting addtional content-type headers / media types for api calls.

---

what's the need

Http requests/responses which contains header other than the allowed ones currently referenced here-dotnot & here-python
are not allowed & give parsing error. Idea is to enable support for additional headers which belong to same category but differ due to RFC's flexibility to support for more specific and informative header types.

Sample cases:

Major Syntax	Some Examples
JSON	application/json, application/problem+json, application/ld+json, application/json-patch+json, application/merge-patch+json
XML	application/xml, application/atom+xml, application/soap+xml, application/rdf+xml
Text	text/plain, text/html, text/csv, text/calendar, text/markdown
Multipart	multipart/form-data, multipart/related, multipart/mixed
Vendor Specific	application/vnd.api+json, application/vnd.github+json, application/vnd.ms-excel

To being with I'd suggest to focus only on JSON based extensions on the format of application/<something>+json referenced in following RFCs:

• RFC 6902

• RFC 7386

• RFC 7807

• This will also enable some of the API like Azure DevOps which expects such content headers. Ref

I can help with the PR for the above but was wondering to know the plan and/or thoughts of maintainers on this & if a common thought is there - happy to work on this.

EDIT: I mistakenly said above that currently it gives parsing errors. I see that it's conciously ignored from a PR. Seems like a thought through step for the time being.

[SergeyMenshykh]

Hi @beyondszine, thanks for volunteering to add support for the application/*+json types. These and others are not yet supported because no one has asked for them. So, please go ahead and open a PR, or ideally, a few small ones to simplify the review process.