Add content::{Accept, ContentType} headers

[yoshuawuyts]

Adds the content::{Accept, ContentType} headers, implementing content negotation for media types. Supersedes #269 which only implemented content::ContentType. Ref #99. Thanks!

[Fishrock123]

I don't think we should merge this until the API for content-type is flushed out more.

As far as I am aware, there are 4 main uses for Content-Type:

• Accept, i.e. negotiation. Covered in this PR.
• Determining file type from http data
• Determining http data from file and/or path
• Determining if a response should be compressed on-demand

The latter 3 are not covered here and are, in my experience, the more necessary usage.

Here's some 23:00 ideas:

• ext() -> &str file extension as string
• From<Path> & from_ext(&str)
• compressible() -> bool

All of these require some kind of in-memory database. I was trying to figure out what structure to use for that but really wasn't sure. However we should populate that database from mime-db, since it is by far the most comprehensive source out there (it is an aggregate plus more).

We could also do mime sniffing... but that's kinda costly, requires intercepting bodies, is possibly less reliable, etc

[yoshuawuyts]

@Fishrock123 To me it sounds like the features you're suggesting may be out of scope for this PR, even if they seem useful. This PR introduces two typed headers only:

• Accept which is used for content negotiation.
• Content-Type which is used to communicate the media type used.

Both headers implement the full spec, and in addition to that we also include the content negotiation algorithm to actually make Accept useful.

Your suggestions around mime-db likely best be implemented as extensions to our existing http_types::mime::Mime implementation. Mime already has some capabilities to infer the type either by reading magic bytes (Mime::sniff) or by attempting to guess the mime from the file extension (Mime::from_extension).

We also already have a direct "create a mime from a file" conversion available through (Body::from_file), which applies both the from_extension and sniff methods to determine the file type. Finally Mime also has a Display impl that can be used to convert it back out to a string. Though a Mime -> file extension conversion may indeed be useful.

In short: I think your suggestions are good, but they don't need to block this PR. I've filed separate issues to track what's not been implemented so we can remember to implement them later:

• Add Mime::into_extension
• Add Mime::is_compressible
• Port mime-db to Rust to enhance our mime extension guessing
• Meta issue to track media type improvements [tracking] Media Type improvements #274

[Fishrock123]

I don't think we should merge this until the API for content-type is flushed out more.

Ah, well, this and the issues from #274 are what I meant by this - i.e. that we have at least made an effort to think about it.

[Fishrock123]

Overall looks good, with some minor fixes & questions.

[Fishrock123]

This comment seems to only be for Accept-Encoding