Change return type of Field::content_type

[davidpdrsn]

It should return some kind of string, or a type axum owns, to avoid the public dependency on mime.

Mime implements AsRef<str> meaning we can probably return &str but should verify that it returns the whole mime type and not just a part.

[nashley]

Why do you prefer a string over mime's enum types? Personally I like being able to match on valid mime types.

It looks like mime has been unmaintained for a while (and will likely continue to be). I'm not sure what a good alternative is though. http-types has mime support, but you probably don't want to pull in that whole library.

[SabrinaJewson]

Why do you prefer a string over mime's enum types?

It says in the issue description - avoiding the public dependency on mime. The purpose is just to avoid having to make breaking changes to Axum should breaking changes be made to mime in future. It would also allow switching Mime implementation without breaking API.

[davidpdrsn]

Yep exactly what @SabrinaJewson said.

[nashley]

Makes sense.

A followup question then: should I expose an enum for mime types within axum, or do you prefer just a string? Either way, I think we'd probably want some (potentially internal) constants for mime types that the server uses like text/plain; charset=utf-8, text/html; charset=utf-8, application/x-www-form-urlencoded, etc. It sounds like you may want to continue to use mime internally, so I'll stick with that.

Perhaps users could be encouraged to parse the strings into enums with other libraries if they so choose? I think that fits into (what I perceive to be) the goal and spirit of axum.

[davidpdrsn]

Yes. We should continue to use mime internally, but expose a string that users can parse into whatever representation is appropriate.

[davidpdrsn]

Fixed in #642