use http_types::mime instead of the mime crate #536
Conversation
jbr
force-pushed
the
use-http-types-mime
branch
2 times, most recently
from
3507a3a
to
8d13df2
Compare
src/fs/serve_dir.rs
Outdated
| @@ -70,7 +71,7 @@ impl<State> Endpoint<State> for ServeDir { | |||
| res.set_body(body); | |||
|
|
|||
| if let Some(content_type) = mime_guess::from_path(&file_path).first() { | |||
| res = res.set_mime(content_type); | |||
| res = res.set_mime(content_type.to_string().parse::<Mime>().unwrap()); | |||
There was a problem hiding this comment.
This is not very nice, should http_types::HeaderValue have an into for this?
There was a problem hiding this comment.
I think this code is temporary and will be replaced by the mime sniffing stuff in http_types
There was a problem hiding this comment.
This is converting from a mime::Mime to a http_types::Mime, and I think the goal is for neither tide nor http_types to have a dep on the mime crate
There was a problem hiding this comment.
http-types Body now has a from_file constructor that applies the inference. Could as maybe use that here?
The trickiest part I see is checking the error type so that we can set the right status codes, but that should be possible through downcasting.
That way we can get rid of the mime dep effective immediately!
Fix the use of the mime crate in the graphql example (brought up by #534), which was a mistake. This pr removes dependence on the mime crate entirely, in preference to http_types::Mime
This pr also allows set_mime to accept an Into, and calls through to the http_types::Response::set_content_type