-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Content-Disposition headers for File types #161
Comments
Well, right now you can create a custom response type to handle this. One question is if setting the Thoughts @shepmaster ? |
I don't believe that we would want to add a Content-Disposition header as browsers already default to On another note I'm still not sure how to create a custom response type for this. I've created a type and web impl as the following: extern crate serde_derive;
#[macro_use]
extern crate tower_web;
extern crate tokio;
use tokio::fs::File;
use std::path::PathBuf;
use std::net::SocketAddr;
use tower_web::ServiceBuilder;
use tokio::net::TcpListener;
use std::env;
#[derive(Debug, Response)]
struct DownloadFile {
#[web(header)]
content_type: String,
#[web(header)]
content_disposition: String,
file: File,
}
#[derive(Debug)]
pub struct StaticFile {
root_dir: PathBuf,
}
impl_web! {
impl StaticFile {
#[get("/library/*relative_path")]
fn m4v(&self, relative_path: PathBuf) -> DownloadFile {
let mut path = self.root_dir.clone();
path.push(relative_path);
let filename = match relative_path.file_name() {
Some(f) => match f.to_str() {
Some(f) => f,
None => "default.m4v",
},
None => "default.m4v",
};
DownloadFile {
content_type: "video/x-m4v".to_string(),
content_disposition: format!("attachment; filename=\"{}\"", filename),
file: File::open(path).into(),
}
}
}
}
pub fn main() {
let addr = match env::var("ADDRESS") {
Ok(a) => a.to_owned(),
Err(_) => "127.0.0.1:8443".to_owned(),
};
let addr: SocketAddr = addr.parse().unwrap();
println!("Listening on http://{}", addr);
tokio::run({
ServiceBuilder::new()
.resource(StaticFile{
root_dir: "/var/lib/www".into(),
})
.serve(TcpListener::bind(&addr).unwrap().incoming())
});
} with following cargo file: [package]
name = "sfile"
version = "0.1.0"
edition = "2018"
[dependencies]
tower-web = "0.3.3"
tokio = "0.1.10"
serde = "1.0.44"
serde_derive = "1.0.44"
futures = "0.1.18" and then I get the following error:
I guess I need to implement a future trait for the DownloadFile type? or is there a better way to do this? |
You need to return a future of the -> impl Future<Item = DownloadFile> You can then just return |
Thanks for the response. I appreciate you looking at this. From what I can tell with the into_future() change the compiler now wants to serialize the file field instead of recognizing the field as a file type. I'm not sure how to prompt it to use that field as a File and not treat it as a serialized json response. So with the example code the error looks like the following:
With the larger code base for my service I get the following error:
Also if I can have it utilize the file response type, I'm thinking that the src/response/file.rs Response implementation will still not add any other headers other than the content_type_header saved in the context. Is that correct? |
So here is a working example using the IntoFuture step you introduced above, via a flat out non-DRY duplication of your File Response trait implemented for the DownloadFile structure. I'm hoping this may clarify what I'm trying to do, if it was not clear before.
|
Ok, I think the derive response macro may need to have an annotation to indicate that the file should be the body and not serialized w/ serde. |
I need to have browsers automatically download some files. Is it currently possible to add a
Content-Disposition: attachment; filename="--file--"
header, where --file-- would dynamically be generated? I send this information along with file mime info for File types I wish to force the file to be downloaded instead of being displayed in the browser. If not what would be the best way to add that feature?The text was updated successfully, but these errors were encountered: