Requested functionality: Multipartform

[gmobydick]

Adding a request for MultiPartform as you suggested in your reply to my question on the documentation pages.

[gmobydick]

Closed by mistake

[tmenier]

Didn't mean to ignore this for so long. Yes, I'd like this for 1.0 I'll (finally) make it a high priority.

[tmenier]

@gmobydick Here is a sneak peek of what a multipart post will tentatively look like in Flurl.Http 1.0:

await "http://httpbin.org/post"
    .PostMultipartAsync(new {
        DataField = "hello!",
        File1 = new HttpFile(path1),
        File2 = new HttpFile(path2, "image/png")
    });

HttpFile is a simple type that takes a local file path and (optionally) a content type. It's in the Flurl.Http namespace (no need for another using), and it tips off the object parser that it needs special handing rather than just serializing to a string like most other types.

I experimented with other fluent-y ways to do it but ultimately I felt this was simplest and fit the anonymous object paradigm nicely.

Thoughts?

[Troto]

Looks good! Can't wait. I've just started using Flurl today and need this. I'm assuming this will support stream content?

Also, somewhat unrelated, is there any way to set the content and then make the call with another extension method? I know I could just call the different content type calls as necessary but it would be nice to just set the content in my method then continue the fluent call structure.

[gmobydick]

I think that's gone work nicely.
Thanks for all your good work.

Rgds,Kurt

Med vennligst hilsen

Kurt Moan
Mobil: 97123411
Email: gmobydick@gmail.com

On Sat, Jun 25, 2016 at 9:24 PM, Todd Menier notifications@github.com
wrote:

@gmobydick https://github.com/gmobydick Here is a sneak peek of what a
multipart post will tentatively look like in Flurl.Http 1.0:

await "http://httpbin.org/post"
.PostMultipartAsync(new {
DataField = "hello!",
File1 = new HttpFile(path1),
File2 = new HttpFile(path2, "image/png")
});

HttpFile is a simple type that takes a local file path and (optionally) a
content type. It's in the Flurl.Http namespace (no need for another using),
and it tips off the object parser that it needs special handing rather than
just serializing to a string like most other types.

I experimented with other fluent-y ways to do it but ultimately I felt
this was simplest and fit the anonymous object paradigm nicely.

Thoughts?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#48 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAUE_GhkZPRd0xMCu-SlJesI_kA8k_8Eks5qPYBlgaJpZM4Fkd8l
.

[ecentinela]

Any idea about when it will be available?

[kroniak]

I think that it will be available at few days by beta7 nuget package. Rtm version will be available after community review.

[tmenier]

Yes, hope to have the beta package released to NuGet this week.

[ecentinela]

Great! Looking forward to this release!

[tmenier]

@Troto Honestly I hadn't planned on doing a multipart overload that takes a stream but it would be easy (easier than a cross-platform-compatible file path actually). I just didn't want to add it if it's not useful - seems like you'd be starting with a file on disk most of the time. Maybe explain the use case? I could be convinced to add it.

As for your other question, yeah, unrelated. :) Not sure I follow, but if it's question please post on SO with a code example; if it's a feature request, create a new issue. Thanks.

[Troto]

@tmenier In my case it would be for the separation of the platform specific work. I'm using Xamarin Forms and have a PCL and I have all the rest service and api stuff in the PCL but I need a specific implementation of the filesystem stuff for droid and iOS so I'd like to be able to just pass a stream back from that platform file service and not pass a path that's specific to a platform to the rest service which probably shouldn't deal with file IO.

As for my other question, I'm simply wondering if there is a way to set the content with a different method to the method that actually sends the request. Currently setting the content of the request and sending it are tied together in one method so if I wanted to intercept the way content is set and change it I can't without also writing the send as well.

[tmenier]

@Troto Stream support is pushed. Similar syntax as above, with new HttpFile constructor:

await "http://httpbin.org/post"
    .PostMultipartAsync(new {
        File1 = new HttpFile(stream, filename, contentType),
    });

contentType is optional but filename is required.

As for your other question, see if these address it: #111 #91

[tmenier]

@gmobydick @Troto @ecentinela Prerelase containing mutipart support as described here is now available:

https://www.nuget.org/packages/Flurl.Http/1.0.0-beta7

Please test and provide feedback.

[ecentinela]

Thank you @tmenier.

I'm testing it now. I have faced a problem due to my limited knowledge of C#. Do you know how can I merge the new "PostMultipartAsync" and "PostJsonAsync"?

For example, I need to something like:

new {
    File1 = new HttpFile("./document.pdf"),
    Recipients = new { email = "email@domain.com", name = "My Name" }
}

[tmenier]

@ecentinela Not really, that's sort of an odd scenario. I'd probably just use Json.NET (comes with Flurl.Http) directly:

new {
    File1 = new HttpFile("./document.pdf"),
    Recipients = JsonConvert.SerializeObject(new { email = ... })
}

[ecentinela]

Thanks @tmenier for your answer, but if I do that, the Recipients is sent as a json encoded string, not really part of a multipart request. Any other suggestion?

[tmenier]

Hmm. Pretty sure the whole thing would still be sent multipart, the problem is you probably want to set content-type: application/json for that part. This could be a showstopper; there needs to be more flexibility in setting each part. I have an idea that won't take me long but it will completely change the API around this. Stay tuned..

[tmenier]

I created a new issue, #113, to replace this one. I may want to link back to the issue to show a code sample, and I think that could be confusing if I link to this issue with syntax at the beginning that is no longer valid.

[tmenier]

@gmobydick @Troto @ecentinela Please see changes to this in #113. This is now available on NuGet:

https://www.nuget.org/packages/Flurl.Http/1.0.0-beta8

Please leave any feedback in #113.