See discussion in https://github.com/ipfs/go-ipfs/issues/5168
We cannot stream responses with keep-alives enabled.
I prefer this to not be a client feature, as otherwise users might end up
shooting themselves in the foot.
Note, the price is a corrupted request body which gets added
normally and gives wrong hashes!
License: MIT
Signed-off-by: Hector Sanjuan <code@hector.link>
No more hacks around /add. This uses the local adder when hijacking /add.
It supports the parameters and works pretty well with the ipfs CLI, showing
progress and everything.
License: MIT
Signed-off-by: Hector Sanjuan <code@hector.link>
Usually we had wrap-in-directory enabled by default because otherwise
we had an error when adding single, non-directory files.
wrap-in-directory happens automatically when adding more than one file
so that was no problem. Thigns also worked when adding a folder and Wrap was
disabled. The only case was adding a single with wrap disabled (a default option).
This patches the ipfsadd/add.go file to remember the last added file so that
we can use it's Cid as the resulting root of the adding process without
having to fetch it from our dummy dagservice.
We have to pass this CID to our Finalize() functions, because it turns out that
in this case (single file without wrap-in-directory), the last block added to the DAG
is not the IPFS root (the ipfsadd/Adder adds the mfs root folder last always).
This was the case when wrap-in-directory was enabled by default.
License: MIT
Signed-off-by: Hector Sanjuan <code@hector.link>
This removes a bunch of the channel dance and block forwarding
by having the adder submodules be DAGServices themselves and take
Add() directly from the ipfsAdder.
License: MIT
Signed-off-by: Hector Sanjuan <code@hector.link>
This was a long FIXME/TODO. Handling adding output and
reporting to the client of the progress of the adding process.
This attempts to do it. It is not sure that it works correctly
(response body being written while the multipart request is still being read)
License: MIT
Signed-off-by: Hector Sanjuan <code@hector.link>
