Update mime crate

[mitsuhiko]

This is more of a suggestion than a bug, but it would appear that modelling mimetypes as anything other than raw strings is ridiculous overkill. Maybe some alternative method can be found where they are represented as a tuple (mimetype, attributes) instead?

This enforces the typing system on it, the same goes for many parts of Hyper. It's actually a great feature, that ensures no cases are forgotten, and will make the compiler yell at you for any typo.

[mitsuhiko]

@MichaelZapataScality I fail to see how that ensures no cases are forgotten. Can you clarify what you mean by that?

On a match? (It may be a bad example though, what I really meant was that you could only get in parts of code dealing with a signature like fn foo(bar: Mime) when you are sure that this is a mimetype, making the signature totally explicit/reliable)

[mitsuhiko]

I fail to see how match is helping though. First of all if something is Ext or not is pretty random at the moment. For instance you ned to use ext for all common vendor mimetypes. Secondly because of ext you can already not handle all. But ultimately you can make up completely bogus mimetypes with the current system anyways (for instance nobody stops you from making an image/json).

A tuple mime type would still be a separate type.

[seanmonstar]

I agree, the mime crate needs some work. I've been working on a re-working of it, where a Mime just has several Name values. the Name struct is wrapper around str that provides some syntax guarantees, such that a Name only includes characters allowed by the spec. Otherwise, all the current variants I've converted into constants, so mime::Json still exists and can be used in match expressions.

[seanmonstar]

The work-in-progress rewrite: https://github.com/hyperium/mime.rs/tree/ng

• Needs something to determine when a parameter can be case-insensitive, such as Charset.
• Operator overloads are cute, but may be the devil.
• Some optimization could be added to reduce the amount of Strings allocated during parsing (such as comparing to a list of common constants).

[puhrez]

👀

[crawford]

But ultimately you can make up completely bogus mimetypes with the current system anyways (for instance nobody stops you from making an image/json).

@mitsuhiko IANA regulates the MIME types, so they would be the ones stopping you. You could make something follow the same string format that MIME types use, but it would not be a MIME type. That's what the type system guarantees.

[mitsuhiko]

@crawford the type system does not guarnatee that at all. As mentioned the type system allows me to construct image/json which is not a registered mimetype.

[seanmonstar]

So it's been a while, but I finally got around to having a redesign I think I like. See hyperium/mime#50