> I'm not sure of your use case where clients can send any format they want and the HTTP server is supposed to know and handle any format automatically (form, j

> I'm not sure of your use case where clients can send any format they want and the HTTP server is supposed to know and handle any format automatically (form, json, querystring, etc) Any server that has clients that aren't fully under your control that you can't force-update, where the clients today and the clients yesterday encode their requests differently. I mean, it's the entire purpose of the `Content-Type` header. The whole concept is that the server has a set of encodings that it can understand, and the client can pick between them. This isn't a new idea. Here it is in RFC 2068, from 1997: https://www.rfc-editor.org/rfc/rfc2068#page-116 https://www.rfc-editor.org/rfc/rfc2068#page-116 These concepts have existed for decades. In your comment, you make an implicit assumption: the assumption is that the person that writes the server is in control of the client. When we make tools that make it easier to construct software that assumes the server operator is in control of the client but do nothing to make it easier to build software in which the server operator is not in control of the client, we are making a political choice to place power in the hands of server operators at the expense of end users. That's not a political choice that I'm comfortable with.