-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Transfer of object.patch.set-data in http API #2070
Comments
the input for set data is passed via stdin (aka, the request body) |
In 0.3.11 it only works as an extra argument in the URL. |
mmmm, no. You definitely can pass file data:
|
unless something really weird is happening and turning that into a url parameter... have you tried it from the cli and checked what request it makes? |
oh weird:
So it can take file input, but apparently the file gets read in and turned into a normal 'string' argument... |
Yep, at the moment this is the only thing stopping us fully using IPFS in Peergos. |
@whyrusleeping can we make this a |
@jbenet its not quite that simple unfortunately... we need to find a way to support arbitrary position arguments between subcommands: |
dammit. we've been able to do this the whole time. |
@ianopolous should be fixed now on dev0.4.0, confirm? |
Hmm, I get a 400 on dev0.4.0 for add-link: I get a similar 400 for the set-data post as well. |
hrm... let me try a few things... |
@ianopolous are you using the js-ipfs-api? |
Nope, the Java one, but I haven't pushed the changes to make the set-data use the http body.. |
@ianopolous alright, you'll have to make a change to the way your url is constructed. A valid one from the CLI looks like:
Note that 'add-link' is no longer an argument, but one of the commands. |
Okay, that's fixed add-link to work again, but set-data still 400s: e.g. |
@ianopolous check the http trailers sent on the request, they should give you error messages (if you don't get anything useful from the body). The data is expected to be multipart to mesh easily with everything else that we use multipart for. On a related note, are there any tests for the java api bindings that we could run in CI? It would be nice if we could see when changes we make here break code that depends on us. |
Ah I didn't realise it had to be multipart. That'll do it. There are indeed tests, run using "make tests" in the root, obviously requiring the jdk to be installed |
@ianopolous cool. We will discuss automated testing of libraries that are dependant on our code during the infrastructure sprint this week. cc @lgierth @RichardLitt |
I've switched it to multipart, but now it gets a 500, and the Trailer response header says: X-Stream-Error |
The url the multipart is using is e.g. http://127.0.0.1:5001/api/v0/object/patch/set-data?arg=QmdfTbBqBPQ7VNxZEYEj14VmRuZBkqFbiwReogJgS1zR1n&stream-channels=true |
@ianopolous is this still an issue? |
@whyrusleeping Not sure why this is still open. You fixed it during that chat we had ages ago. All is good now. :-) |
The data in object.patch.set-data is stored in the URL. This is quite limiting if I want to put arbitrary binary data there (esp if I want ~512kb). Would putting the data in the request body or a multi-part make sense?
The text was updated successfully, but these errors were encountered: