cmds/2 ipfs add -r should use multipart

[jbenet]

Requires http multipart or something

[jbenet]

Band aid fix in 1365d64

[jbenet]

Grabbing from #263:

---

Maybe it's Content-Disposition?

• http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html
• http://www.huyng.com/posts/under-the-hood-an-http-request-with-multipartform-data/

---

@mappum said:

Maybe it's Content-Disposition?

That's for filenames, so we will use that too, but not for full paths ('foo.txt' vs '~/textfiles/foo.txt').

The RFC says http://tools.ietf.org/html/rfc2183#section-2.3:

The receiving MUA SHOULD NOT respect any directory path information
that may seem to be present in the filename parameter. The filename
should be treated as a terminal component only. Portable
specification of directory paths might possibly be done in the future
via a separate Content-Disposition parameter, but no provision is
made for it in this draft.

So, SHOULD NOT, means we can. :D We can also define our own header. shrug this won't interop with non-ipfs web servers so we get to set w/e we want.

[mappum]

So, SHOULD NOT, means we can. :D We can also define our own header. shrug this won't interop with non-ipfs web servers so we get to set w/e we want.

Ah, you're right. That will probably be the best place to put it (and it's trivial to switch to a custom header later if we find other HTTP client libraries don't support this well).

[mappum]

This change will be almost completely contained inside the commands/http subpackage, just affecting the client and parser. However, we do need to make one change to the external API: since the multiparts are transferred serially, we can't use the Request#Arguments() slice abstraction.

Any ideas how we should let commands access the parts? First thing that comes to mind is an object returned from req.Streams() with Next() and HasNext() methods to access the parts. (But Next wouldn't be able to be called until the current stream is all the way read :/).

[jbenet]

addressed in #357