Stream automatically gets closed. Can we make this optional?

[peter-shinydocs]

This is generally an amazing idea. But it would be nice if we could choose to save the stream.

Flurl/src/Flurl.Http/FlurlRequest.cs

Line 199 in 3f28388

request.Dispose();

[tmenier]

You want to save the request stream? Can you elaborate on what you're trying to do?

[peter-shinydocs]

I am processing a file multiple times. After reading the file into a stream I send it to its first endpoint for processing. After I call the SendAsync(...) The stream is disposed and I can no longer access it. Maybe I'm missing something.

…

On Tue., Sep. 28, 2021, 20:48 Todd Menier, ***@***.***> wrote: You want to save the *request* stream? Can you elaborate on what you're trying to do? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#650 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AONPC7VOX7NISP5VDTWSCITUEJO5DANCNFSM5ET6V6XQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[tmenier]

I'm not sure how you'd do that without reading the whole file into memory. Otherwise, even if Flurl didn't dispose the request, I don't think you'd be able to read the stream twice. If it's not a huge file, I'd read it into a byte array and send that twice. If it's too big for that, just read it off disk (or wherever it's coming from) twice. If you think I'm missing something, maybe a code snippet would help.

[peter-shinydocs]

Hah I think you are already reading my mind. The file is being read into a RecycleableMemoryStream to avoid the 2gb limitation of byte[] in c#... I could possibly inherit the class and override the dispose to do nothing and then add another method to dispose the stream properly.

…

On Wed., Sep. 29, 2021, 21:57 Todd Menier, ***@***.***> wrote: I'm not sure how you'd do that without reading the whole file into memory. Otherwise, even if Flurl didn't dispose the request, I don't think you'd be able to read the stream twice. If it's not a huge file, I'd read it into a byte array and send that twice. If it's too big for that, just read it off disk (or wherever it's coming from) twice. If you think *I'm* missing something, maybe a code snippet would help. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#650 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AONPC7RKDJ3EPI362AOBSHTUEO7XXANCNFSM5ET6V6XQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[tmenier]

If it's over 2gb I'd really encourage you to keep it simple and just read it from storage twice.

[ArturMarekNowak]

@tmenier but if it is a temporary Filestream which I want to delete on close, lack of the ability to keep it open after request is problematic. Of cource I could make deep copy just before the request but it would double RAM used. It would be much simpler if flurl simply didn't dispose it

[tmenier]

Re-opening, I'll give this a fresh look for 4.0. Need to re-evaluate whether this is the right place to dispose the request (if at all), whether streams should be handled differently, or to your point whether it should somehow be optional.

[tmenier]

Sorry for the long delay on this one. I'm of the opinion that the Dispose call can simply be dropped.

aspnet/Security#886

It should be assumed by the developer that if they provide a stream for the request content, they are on the hook for managing it. I'll drop that line for 4.0.

[sanyappc]

Maybe we should add Dispose here now?

[tmenier]

@sanyappc What would be the reason for doing that? Can you explain?

[sanyappc]

@tmenier The PostMultipartAsync method creates CapturedMultipartContent itself, so I think it should Dispose it after executing SendAsync

I thought so at first, but now I'm not so sure

[tmenier]

@sanyappc I think the same argument for not disposing applies if you're doing multipart - it's only important if you're providing a stream, and you may or may not want it closed immediately.

[petervanleeuwen]

Thank you! Sorry I wish I could have made an attempt.