Add an encapsulated file stream in axum-extra to make it more conveni…

[YanHeDoki]

Motivation

In use will need to return a file stream, encapsulates a file stream structure to save the return time to add the header

Solution

In axum-extra add a response structure, the construction needs to pass a file stream, in the response will add the header: “application/octet-stream”, I added the documentation and examples these will be more detailed

 use axum::{
     http::StatusCode,
     response::{Response, IntoResponse},
     Router,
     routing::get
 };
use tokio::net::TcpListener;
 use axum_extra::response::file_stream::FileStream;
 use tokio::fs::File;
 use tokio_util::io::ReaderStream ;

#[tokio::main]
async fn main() {
    let app = Router::new().route("/", get(file_stream));
    let listener = TcpListener::bind("127.0.0.1:3000").await.unwrap();
    axum::serve(listener, app).await.unwrap();
}

 async fn file_stream() -> Result<Response, (StatusCode, String)> {    
     let     stream=ReaderStream::new(File::open("file_path").await.map_err(|e| (StatusCode::NOT_FOUND, format!("File not found: 
       {e}")))?);
     let file_stream_resp = FileStream::new(stream)
         .file_name("You want to set the file name");

     Ok(file_stream_resp.into_response())
 }

See examples/stream-to-file for a short demonstration I've added usage to this example.

I just started using rust, so some of the code may not be well written

[yanns]

This is looking good to me 💯

[yanns]

Can you add an entry in the https://github.com/tokio-rs/axum/blob/main/axum-extra/CHANGELOG.md ?

[YanHeDoki]

Can you add an entry in the https://github.com/tokio-rs/axum/blob/main/axum-extra/CHANGELOG.md ?

Yes, I added it.

[jplatte]

There's a few things I'd like to see improved before we ship this, but maybe it's easier if we merge now and I post a follow-up PR. It's nothing big.

[YanHeDoki]

There's a few things I'd like to see improved before we ship this, but maybe it's easier if we merge now and I post a follow-up PR. It's nothing big.

Okay, I improved it. Can you review it again？

[ttys3]

the usage of this PR feature seems rather limited.

for example, it seems that it does not handle HTTP range requests

and it limited the response header. it fixed to application/octet-stream and attachment; filename=xxx

and even in download mode, it does not support inline, only support attachment model.

people may want to steam a video file, and need HTTP range requests support. application/octet-stream is too limited.

as a framework, the feature builtin should be more general.

I suggest put this as an external crate, if it is limited to application/octet-stream

what do you think? @yanns @jplatte

[yanns]

@ttys3 yes I see your point.
It's a bit sad for @YanHeDoki to receive this feedback after many iterations, but I guess it's the right decision.
@YanHeDoki would you mind putting this code into an external crate and add it to the ecosystem?

[jplatte]

Wait, why would we not add stuff like range header support to this and have it in axum-extra then? It's a very common feature request.

[YanHeDoki]

I added file streaming support for range headers with the try_range_response and into_range_response methods, also add documentation and tests and use examples

I just wanted simple support for streaming file downloads, so I didn't make it complicated, and perhaps it should have been added to the attachment feature would have been better. maybe continue to improve the functionality

@yanns @jplatte

[YanHeDoki]

@ttys3 yes I see your point. It's a bit sad for @YanHeDoki to receive this feedback after many iterations, but I guess it's the right decision. @YanHeDoki would you mind putting this code into an external crate and add it to the ecosystem?

But as a standalone crate is it too simple, maybe it should be added to the attachment feature?

[jplatte]

I still think it makes sense to have this as a feature. It's independent of Attachment in its purpose, and can be combined with it if wanted.

[jplatte]

I've pushed a bunch of minor changes, hope that's fine. Previous review comments should still be valid.

[jplatte]

Thank you! I think there's still some improvements to be done, but that can be done separately.