Multipart Uploading #172

jalcine · 2022-02-26T13:22:37Z

jalcine
Feb 26, 2022

I'm attempting to implement https://docs.rs/multipart/latest/multipart/server/trait.HttpRequest.html for https://docs.trillium.rs/trillium/struct.conn (at least by pulling out the specific header and body). Is there a suggestion here on how to do this? This is what I've considered doing so far (to no avail - this example will not compile):

pub struct MultipartRequest<'r> {
    boundary: Option<String>,
    body: ReceivedBody<'r, BoxedTransport>,
}

impl<'r> multipart::server::HttpRequest for MultipartRequest<'r> {
    type Body = &'r mut dyn std::io::Read;

    fn multipart_boundary(&self) -> Option<&str> {
        self.boundary.map(|s| s.as_str())
    }

    fn body(self) -> Self::Body {
        block_on(self.body.read_bytes()).unwrap()
    }
}

jalcine · 2022-02-26T13:57:33Z

jalcine
Feb 26, 2022
Author

Considering using https://docs.rs/multipart/latest/src/multipart/mock.rs.html#152-165 as an example.

5 replies

jalcine Feb 26, 2022
Author

Yeah, this works. Going to implement a handler that allows for more options like max size and allowed content types (working on something that can upload images and archives).

jalcine Feb 26, 2022
Author

*Implement a handler and publish it as a crate (probably trillium-multipart)

jalcine Feb 26, 2022
Author

Right now, I'm trying to confirm this work (within another project before I extract it to a crate) and I'm getting an error with an upstream crate with the following test case:

#[test]
fn multipart_parsing() {
    use trillium_router::Router;
    use trillium_testing::assert_ok;
    use trillium_testing::TestConn;
    let r = Router::new().post("/upload", move |mut conn: Conn| async {
        let b: Result<RequestBody<String>, _> = conn.from_request(None).await;
        conn.send_response(b.and(Ok(trillium::Status::Ok)))
    });

    let conn: TestConn = TestConn::build(
        "post",
        "/upload",
        r#"
--trillyTrill
Content-Disposition: form-data; name="text"

text default
--trillyTrill
Content-Disposition: form-data; name="file1"; filename="a.txt"
Content-Type: text/plain

Content of a.txt.

--trillyTrill
Content-Disposition: form-data; name="file2"; filename="a.html"
Content-Type: text/html

<!DOCTYPE html><title>Content of a.html.</title>

--trillyTrill--
"#,
    )
    .with_request_header("content-type", "multipart/form-data; boundary=trillyTrill");
    assert_ok!(dbg!(conn.run(&r)));
}

Notes:

from_request is a function from a custom trait on Conn that, depends on the Content-Type parses out a payload.
send_response is a function from a custom trait that can take a value that implements Into<Response> and does something a bit like conn.with_status(response.status).with_header(response.headers).with_body(response.body).halt() - a convenience wrapper.

jalcine Mar 11, 2022
Author

Here's the from_request impl and send_response impl

jbr Mar 11, 2022
Maintainer

Hey there, taking a look at this — the current behavior looks pretty similar to trillium-api, but that also doesn't address the need for an async multipart parser. It would work to use the multipart crate in the subset of use cases where the entire body can be held in memory, but if for example we need to stream a multipart file directly to disk, we'd need a new multipart parser. I've started in on this a few times. The parser itself probably shouldn't have anything to do with trillium, and should just operate on any AsyncRead body. I'll take a look at this again, but in the short term if you can hold the body in memory, the multipart crate would work great.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Trillium

Multipart Uploading #172

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment 5 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Trillium

Multipart Uploading #172

Uh oh!

jalcine Feb 26, 2022

Replies: 1 comment · 5 replies

Uh oh!

jalcine Feb 26, 2022 Author

Uh oh!

jalcine Feb 26, 2022 Author

Uh oh!

jalcine Feb 26, 2022 Author

Uh oh!

Uh oh!

jalcine Feb 26, 2022 Author

Uh oh!

jalcine Mar 11, 2022 Author

Uh oh!

jbr Mar 11, 2022 Maintainer

jalcine
Feb 26, 2022

Replies: 1 comment 5 replies

jalcine
Feb 26, 2022
Author

jalcine Feb 26, 2022
Author

jalcine Feb 26, 2022
Author

jalcine Feb 26, 2022
Author

jalcine Mar 11, 2022
Author

jbr Mar 11, 2022
Maintainer