seanmonstar / reqwest

An easy and powerful Rust HTTP Client
https://docs.rs/reqwest
Apache License 2.0
9.92k stars 1.12k forks source link

static lifetimes on Multipart? #1826

Closed bitfl0wer closed 1 year ago

bitfl0wer commented 1 year ago

I am developing a library which uses reqwest for all the HTTP stuff. The library has to send file attachments in a Multipart Form, and I was more than pleased to find out, that reqwest supports those! However, there is something which I find quite odd:

File attachments in a Multipart form get constrained to have a static lifetime (example: adding Part::bytes<t> to a form requires T to have a static lifetime)

File attachments can potentially be arbitrarily sized: from 1kb to a whole Gigabyte - everything is possible. I'd quite like to not keep this whole potential Gigabyte in my program's memory for it's entire runtime. I have already thought of a workaround for my code, but I am wondering about the reason for this static requirement. Sure, attachments have to be valid at least until the form gets sent, but this could be solved by using a less restrictive lifetime requirement, no (genuine question here - I have only been coding in rust for about a month now)?

seanmonstar commented 1 year ago

For large files, you could use the Part::stream constructors. Those will only read portions of the file at a time.

bitfl0wer commented 1 year ago

Thanks! I am not sure I understand for myself though - If files have to be static because they still have to be alive at time of sending the request, then why doesn't the same apply to streams? Also, my original question is still open :P

Edit: file_name also requires the argument to be static, even if I use stream instead of bytes. I am kind of stuck

seanmonstar commented 1 year ago

The Part::bytes constructor is a meant to be used when you want to make a part with a smallish bucket of bytes, since you already have them in memory. Part::stream will only read a portion, and send it on the socket, and then it will read some more once the socket is ready to send more. The File stays alive that whole time, but it's just a handle to a location on the disk. It doesn't store all the data it has in memory.

The string representing the file-name must be static, meaning it can't be borrowing some data from anywhere else. It's enough to just make a String or similar. Like /home/sean/Documents/zap.txt. Just that string, not the contents of the file. That can be streamed.

bitfl0wer commented 1 year ago

sorry i am stupid, i read on 'static and what it actually implies and it turns out that i was being dumb

thank you for your answers and your time, it is much appreciated