I'm willing to attempt this if it hasn't been assigned yet and would be accepted.

The PR for this will probably be quite small but will only be acceptable once we've gathered all the other semver-major changes, so it may sit for a while and possibly have conflicts.

@Fishrock123 Do you want me to go ahead and create it but let it sit there, or just wait until other semver-major changes are implemented?
Thanks

And, by the way, if you're looking for contributors for some of these other semver-major issues, I'm open to doing any that are delegated to me. I'm looking to help out however I can.

You can open a PR if you'd like, just be aware of those things.

@yoshuawuyts Checking back to confirm this: while MediaType is descriptive, MIME is a "term of art", as well as being shorter. The tradeoff here seems like "more descriptive" (MediaType) versus "more conventional and more convenient" (Mime).

"In order to get the media type, call the content_type method on the request"

then why not ContentType? It also makes sense to me.

A new set of HTTP specs has just been published, and in the newly stabilized RFC 9110: HTTP Semantics, 8.3: Content-Type defines the Content-Type header like this:

Content-Type = media-type

There's probably a wider question how we want to work with the new specs that's worth its own conversation. Overall they seem like a much needed improvement over the older specs in terms of clarity and consistency. I'm kind of inclined to say that we should start following the terminology used by them, but use aliases to link back to current, commonly-used terminology. In this case that would mean naming the type MediaType, but adding a doc alias so when someone searches for Mime they can find it too.