Issue adding attachments to documents in CouchDB - json

I'm having problems adding attachments in CouchDB. First off, when I ran the test suite in Futon I got two errors - one in attachments, and another in replication. The error specific to attachments isn't particularly helpful -
name
attachments
status
error
duration
6112
details
0
Exception raised: {}
Some internet commentary says that a few errors in the test suite is perfectly normal, so I moved on. However, attachments are definitely not working properly, either via Futon or Curl. In Futon, the file will generally attach, but only after I click cancel on the upload - i.e. it hangs on the upload progress bar indefinitely until I click cancel. I'm accessing futon on a remote machine via ssh -L5984:127.0.0.1:5984 root#myServer and then pointing Firefox at localhost:5984/_utils/. I don't know if that could be making a difference.
When I try to upload via Curl, using the command
curl -vX PUT http://127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af/ artwork.jpg?rev=9--43332bfae07884c683b50ffd4b8ee18c --data-binary #artwork.jpg -H "Content-Type: image/jpg"
I get:
Host: 127.0.0.1:5984
Accept: /
Content-Type: image/jpg
Content-Length: 11205
Expect: 100-continue
< HTTP/1.1 100 Continue
< HTTP/1.1 400 Bad Request
* HTTP error before end of send, stop sending
{"error":"bad_request","reason":"invalid UTF-8 JSON"}
The log file shows:
[debug] [<0.103.0>] 'PUT' /albums/6e1295ed6c29495e54cc05947f18c8af/ {1,1}
Headers: [{'Accept',"*/*"},
{'Content-Length',"11205"},
{'Content-Type',"image/jpg"},
{"Expect","100-continue"},
{'Host',"127.0.0.1:5984"},
{'User-Agent',"curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3"}]
[debug] [<0.103.0>] OAuth Params: []
[error] [<0.103.0>] attempted upload of invalid JSON (set log_level to debug to log it)
Followed by a huge block -
[debug] [<0.103.0>] Invalid JSON:
<<255,216,255,224,0,16,74,70,73,70,0,1,1,0,0,1,0,1,0,0,255,219,0,132, ... , etc
The final two lines in the log that are relevant to the attempted upload are
[info] [<0.103.0>] 127.0.0.1 - - 'PUT' /albums/6e1295ed6c29495e54cc05947f18c8af/ 400
[debug] [<0.103.0>] httpd 400 error response: {"error":"bad_request","reason":"invalid UTF-8 JSON"}
Does anyone have any idea what is going on here? I tried wrapping the string in the curl request around ' ' in case bash was eating the quotes, it made no difference.

There is a spurious space in your curl command after the slash between the doc id and the attachement:
...f18c8af/ artwork.jpg?...
^
Does it work when you remove it?

There were two problems. The first was the spurious space that Simon pointed out - tyvm. The other problem was where the rev-x details are placed. I was using the format in the book http://guide.couchdb.org/editions/1/en/api.html.
Original command:
curl -vX PUT http://127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af/ artwork.jpg?rev=9--43332bfae07884c683b50ffd4b8ee18c --data-binary #artwork.jpg -H "Content-Type: image/jpg"
Working command (space removed & rev placed in the correct order):
curl -vX PUT http://127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af/attachment?rev=9-43332bfae07884c683b50ffd4b8ee18c --data-binary #artwork.jpg -H "Content-Type: image/jpg"

Related

Ricoh Theta Z1 Doesn't Accept My Request to Change File Format

I am using a Ricoh Theta Z1 updated to the most recent firmware (1.60.1). I am trying to debug an Android application, but I found that one of our commands was repeatedly failing, so I connected to the camera directly from my dev box and tested the protocol directly via curl.
It's my understanding from the documentation that this command should work:
$ curl -X POST -H "Content-Type: application/json; charset=UTF-8" -d '{"name":"camera.setOptions", "parameters":{"options":{"captureMode":"image","fileFormat":{"height":3360,"type":"jpeg","width":6720}}}}' http://192.168.1.1/osc/commands/execute
But when I run this command I get this response:
{"error":{"code":"invalidParameterValue","message":"Any input parameter or option name is recognized, but its value is invalid."},"name":"camera.setOptions","state":"error"}
This in spite of the fact that when I ask the camera about its options, it responds with the exact block it has just told me wouldn't parse:
$ curl -X POST -H "Content-Type: application/json; charset=UTF-8" -d '{"name":"camera.getOptions", "parameters":{"optionNames":["clientVersion","captureMode","fileFormat"]}}' http://192.168.1.1/osc/commands/execute
gets this response:
{"name":"camera.getOptions","results":{"options":{"captureMode":"image","clientVersion":2,"fileFormat":{"height":3360,"type":"jpeg","width":6720}}},"state":"done"}
Furthermore, when I run the first command and omit the fileFormat parameter, the command executes just fine.
Any ideas what I am doing wrong here?
After a bunch of trial and error, I discovered that it is possible to use camera.setOptions to set the file format on the camera, but only if the fileFormat block is the only member of the options block. That is to say, this command:
$ curl -X POST -H "Content-Type: application/json; charset=UTF-8" -d '{"name":"camera.setOptions", "parameters":{"options":{"fileFormat":{"height":3360,"type":"jpeg","width":6720}}}}' http://192.168.1.1/osc/commands/execute
will succeed. I think this must be a bug in the Theta Z1 camera, because as far as I can discern from the docs (https://api.ricoh/docs/theta-web-api-v2/commands/camera.set_options/ and https://developers.google.com/streetview/open-spherical-camera/reference/camera/setoptions), there shouldn't be any restriction on what JSON goes into the options block. In any case, the workaround is simple enough: issue one command to set the file format and one or more as necessary to set the other options, and then you're good to go.
FYI, there is a similar bug with dateTimeZone. see this post
https://community.theta360.guide/t/how-setup-datetime-on-theta-camera-using-web-api/6572/3?u=craig
It seems like there are a few options that need to be set as a standalone option.
If you want to set dateTimeZone, it must be the only option set. I reported this to RICOH. I am going to post your findings on the community.theta360.guide forum to make it easier to find. Thanks.

Why is wget POST giving 400 Bad Request?

I am trying to use wget to POST a .json file to a site using the REST api. Specifically I am trying to create an issue in JIRA from my command line. I am aware that the easiest way to do this is using cURL; however, Solaris' native compiler has an issue with cURL versions before 7.49.0, so I can't connect via https which is a requirement, and I can't update cURL as I'm working on a company machine.
Every time I try to use wget to POST I get an ERROR: 400 Bad Request. It occurs to me that usually this is a problem with the json I'm trying to send but I can't for the life of me figure out what is wrong.
OS: Solaris 10
Version: wget 1.9.1
Command:
wget --post-file=data.json --http-user=[userID] --http-passwd=[userPass] --header="Content-Type: application/json" -i "uri.txt"
data.json:
{
"fields": {
"project":
{
"id": "10200"
},
"summary": "Creating issue remotely.",
"description": "Creating of an issue using project keys and issue type names using the REST API",
"issuetype": {
"name": "Story"
},
"customfield_11600": {
"id": "11303"
}
}
}
UPDATE:
I think my header is not correct when I send out my http POST. In my wget command above I set the Content-Type to application/json; however, looking at the debug information there is two Content-Type spaces in my header.
Content-Type: application/x-www-form-urlencoded
Content-Length: 175
Content-Type: application/json
Could it be that I'm setting my Content-Type incorrectly and the POST is being sent with the wrong encoding?
UPDATE 2
I think I've ruled out the above update as an issue, as removing the application/json content-type gives a 415 Unsupported Media Type error, implying that adding it makes the POST send the correct media type.
I've gotten a curl command to work properly on my windows machine and it connects via http1.1 automatically while wget connects via http1.0, I believe that when connecting via http1.0 the data being sent is appended on the end of the URI. Could this be why the server believes the json to be incorrect?

Google Drive Resumable Uploads

I am having trouble requesting the current status of a resumable upload. Based on the Google Documentation, the following request should return a Range header with the current range google has of my upload, but I keep getting the following response:
Failed to parse Content-Range header
Here is my curl request:
curl -H "Content-Range: bytes */1443452365" -H "Content-Length: 0" locationUrl -X PUT
I have also tried "bytes */*" and "*/*" for the Content-Range header, but no luck.
Any ideas?
First, you need to check the correct request format like the sample given below:
curl -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"id":100}' http://localhost/api/postJsonReader.do
And, discussed in other command-line tools, when sending raw HTTP data, be aware that the POST and PUT operations will require computing the value for a Content-Length header. You can use the UNIX tool wc to compute this value. Place all the content of the HTTP body into a text file such as template_entry.xml (example used above) and run wc -c template_entry.xml. It is often difficult to debug if you accidentally use an incorrect value for the Content-Length header.
Lastly, you can request the status between chunks, not just if the upload is interrupted. If the upload request is interrupted, follow the procedure outlined in resume an interrupted upload.

how to post with curl to REST/JSON service?

I have tried out the sample REST JSON service at
http://www.javacodegeeks.com/2013/04/spring-mvc-easy-rest-based-json-services-with-responsebody.html
and the JQuery client can successfully post a person object to the service! Yahoo!
How do I do the same thing with cURL?
Here is my attempt:
curl -i -X POST -H "Content-Type: application/json; charset=UTF-8" -H "Accept: application/json" -d "{'name':'siegfried','age':26}" http://localhost:8080/api/person
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 71 100 42 100 29 39 26 0:00:01 0:00:01 --:--:-- 40
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Content-Length: 42
Server: Jetty(6.1.25)
Saved person: Person [name=null, age=null]
Compilation finished at Sun Dec 08 22:14:05
It is not parsing the data! How do I make it parse my json data?
I've been google searching for hours and trying out many combinations of escaping quotes and apostrophes and the like and nothing seems to work.
Thanks
siegfried
The -d will send your data as a post, you do not need to declare POST.
man curl gives the description on how to use -d. If anyone else would need it.
A simple Sinatra server http://www.sinatrarb.com, or something like it, can be used to debug your curls as well as a mock server
Is there a possibility that the problem is on the server-side, if you run it on local host you should have access to it, right?
I found the problem!
The spring #ResponseBody uses JSON for get but uses URL Encoding for POST.
See the jQuery POST method for http://codetutr.com/2013/04/09/spring-mvc-easy-rest-based-json-services-with-responsebody/
Why the inconsistency? This drove me nuts!
Well, I still don't have a cURL command. But I do have java and groovy clients that can now POST and GET. I should have a cURL soon.

curl get json returns 404

I'm running a tomcat server with a REST service on localhost.
This url typed in the browser gives me a json response: http://localhost:8080/a/rest/dataset/list
But when I use curl: curl http://localhost:8080/a/rest/dataset/list the response is HTML code with a 404 error from the server.
What am I missing in the curl command?
Tomcat may be waiting for a specially formatted HTTP request from the user. As you are expecting a response in json, you should probably forward the following argument to curl :
-H 'Content-Type: application/json'
Also, you may always specify to whatever HTTP server the response you are expecting him to return. A lot of back-end application based on HTTP are issuing a response given the HTTP request.