Added basic support for multi-part form uploads in HTTPClient

[etcimon]

This still needs a test, but the logic should be right. These two objects (file, memory) will cover 99% of what's usually needed in multi-part form uploads. The alternative to using these is a lot of boilerplate and some specialized low-level protocol knowledge.

I'll write the test to complete the pull request if the structure is satisfying.

[etcimon]

Any comments on the interface for this in general? Should I make the headers editable after the object is created?

[s-ludwig]

Needs to be reformatted to be rendered properly in the documentation:

/** Writes a multipart form as a body to the request.

    This must be written in its entirety because the Content-Length
    must be known beforehand.

    Usage: `req.writeBody(new FileMultiPart(req.headers, "Photo", "images/picture.jpg"));`
*/

Ideal would be to put the example into a documented unit test to verify that it doesn't get out of date.

[s-ludwig]

Instead of putting the headers (and string data) into MemoryStreams, it would be good to instead directly write to the connection. I guess a similar approach as used for writeJsonBody can be used here (i.e. once generate the output on a special counting range to determine the length and then generate again and write to a StreamOutputRange). formattedWrite could also be used to make the header generation code a bit shorter.

[etcimon]

Instead of putting the headers (and string data) into MemoryStreams, it would be good to instead directly write to the connection.

I think the headers need to be kept aside until being written because the multipart forms were designed like linked lists and can be nested, and the content-length needs to be known beforehand in many browsers/parsers.

[s-ludwig]

I think the headers need to be kept aside until being written because the multipart forms were designed like linked lists and can be nested, and the content-length needs to be known beforehand in many browsers/parsers.

What about my suggestion to use a counting range to determine the length? I guess that should be pretty fast and should be an overall win over using dynamic memory allocations.

[etcimon]

What about my suggestion to use a counting range to determine the length? I guess that should be pretty fast and should be an overall win over using dynamic memory allocations.

I have a hard time visualizing it, but as long as you have the length before you start writing the body it should be fine. After all, writePart doesn't support chunked transfer and content-length header is required so the name "Part" is a little misleading, it should be writeMultiformBody or something like that.

[WebFreak001]

@s-ludwig can you merge either this or #1876? I think this is a very useful feature and shouldn't have both PRs left unmerged

[dariusc93]

Any update in regards to adding multipart for HTTPClient? Other than the conflicts github is reporting, is there anything else that would be required for this to get pulled into vibe-d or is there already a multipart implementation in works that isnt pushed into the master branch?