use http_types::mime instead of the mime crate#536
use http_types::mime instead of the mime crate#536yoshuawuyts merged 6 commits intohttp-rs:masterfrom
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
|
|
||
| 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!
yoshuawuyts
left a comment
yoshuawuyts
left a comment
There was a problem hiding this comment.
We should probably ensure in http-types that we return the right status codes here — but that's worth filing an issue for. Otherwise this looks good!
3 participants
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