Orion context broker - Bad Input JSON Parse Error on quite long attribute value - fiware-orion

Are there any known limitations on the length of values of an attribute or a metadata value?
On setting a quite long string (>30-40k chars) at attribute value I am receiving a
WARNING#13:45:37 jsonRequest.cpp[225]: Bad Input (JSON Parse Error)
DEBUG#13:45:37 UpdateContextResponse.cpp[60]: destroyed
DEBUG#13:45:37 UpdateContextResponse.cpp[74]: destroyed
WARNING#13:45:37 jsonRequest.cpp[233]: Bad Input (JSON Parse Error: <unspecified file>(1): expected end of input)
DEBUG#13:45:37 RestService.cpp[126]: result: '{
"errorCode" : {
"code" : "400",
"reasonPhrase" : "Bad Request",
"details" : "JSON Parse Error"
}
}
version 0.25.0 (git version: a8cf800d4e9fdd7b4293a886490c40309a5bb58c)
Using this post command:
curl localhost:1026/v1/updateContext -s -S --header 'Content-Type: application/json' --header 'Accept: application/json' -d #entity1.json -v
and entity json
entity1.json:http://pastebin.com/Esraq80S
Observed behavior:
On cleaned db (removed all entities) and service restarted the post is succesfull in the 1st time and fails in the following ones.
Thanks a lot!!

Based on user report (see coments thread on the question post), upgrading to Orion 1.1.0 solves de problem.
The cause of the problem in 0.25.0 remains unknown. The changelog from 0.25.0 to 1.1.0 at https://github.com/telefonicaid/fiware-orion/releases could be carefully examined in order to find the fix, but probably it doesn't worth the time.

Related

DELETE with wrong header returns 404 although entity is existing

We accidentaly inserted entities into orion using the wrong header (typo)
fiware-service-path instead of the correct one fiware-servicepath (withouht the last hyphen) and now I am unable to delete the entities. I also tested the python script delete_entities_by_query directly on the server without any authorization and that also returns a list of entities.
There are 61 entities
There are 0 pages of 500 entities (and a final page of 61 entities)
Trying to delete always result ins a 404 although the following query returns entites:
--header 'fiware-service: something' \
--header 'fiware-service-path: asdf' \
--header 'Authorization: Bearer TOKEN'
e.g. returns an entity
id:urn:ngsi-ld:6c99ecaa-5cee-4f27-b936-3ccbe8c42d66
DELETE:
curl --location --request DELETE 'https://<orion>/v2/entities/urn:ngsi-ld:6c99ecaa-5cee-4f27-b936-3ccbe8c42d66' \
--header 'fiware-service: something' \
--header 'fiware-service-path: asdf' \
--header 'Authorization: Bearer TOKEN'
returns a 404.
{"error":"NotFound","description":"The requested entity has not been found. Check type and id"}
The right header to specify service path in Orion is fiware-servicepath (not fiware-service-path). Maybe that is the cause of the problem (the fiware-service-path header is ignored by Orion, so it assumes fiware-servicepath: / implicitly, the entity is not found there and 404 is returned).
Note also that the syntax for service path mandates to start with /. Thus, asdf is not a valid service path, while /asdf is.

Uploading big samples for analysis giving unexpected response

While doing the 'POST' request to 'https://de.api.labs.sophos.com/analysis/file/static/v1', I am getting 'HTTP content length exceeded 10485760 bytes.' response.
I know there is a limit to file size we can upload, but earlier we used to get '{message: 'Request Too Long'}' for bigger files(e.g. b28e99d046ac108830a3f5cf0f8eb485b7ce1abafe4d516fba5b4c71cec57fed), which is easier to parse because of JSON.
I am trying to upload sample with sha256 'e102238100a8b97d22559065e3b19379757aeda932c36916d2c84a4178921854'.
Request-
curl -X POST \
https://de.api.labs.sophos.com/analysis/file/static/v1 \
-H 'Authorization: <redacted>' \
-H 'content-type: multipart/form-data' \
-F file=#/tmp/e102238100a8b97d22559065e3b19379757aeda932c36916d2c84a4178921854
So, is there any standard response we will get while uploading big sample size?
The best practice would be to check the response's status code before parsing the response body, so in your case, running curl with the -i or -v option would expose this information to you.
Due to infrastructural limitations, submitting an oversized file up to ~6MB results in a HTTP 413 response, and above that, you can get error messages like 'Remote end closed connection without response' or 'Broken pipe', without a status code.
While the file size restriction may be subject to change in the future, currently there are no plans to change this behaviour.

"The revision must be specified." error with status 400 Bad Request when delete controller-services and connections

I try export and import nifi templates via nifi rest api; but when i tried to delete controller-services, connections or import a template i get the response message "The revision must be specified." with '400 bad request' status from nifi rest api. I didn't understand what i have to do.
This my request for delete a control-service,
request "/controller-services/{id}" (id is, The controller service id.)
curl -X DELETE \
http://localhost:8090/nifi-api/controller-services/015b1030-a099-13d3-812c-77772afcaeb0 \
-H 'cache-control: no-cache' \
-H 'content-type: application/x-www-form-urlencoded' \
and the response is "The revision must be specified."
status : "400 Bad Request"
Any idea please?
I finally got some answers about my mistake after reading this article
It seems you have to add two information to request url; version and clientId.
After make a call and get a component form nifi instance, it sends a version number inside a DTO to you as explained here
like this:
and finally i made a call like below and it worked:
curl -X DELETE \
'http://localhost:8090/nifi-api/controller-services/015b1030-a099-13d3-812c-77772afcaeb0?version=0&clientId=5ed15669-015d-1000-99cf-bc9c6f378085' \
-H 'cache-control: no-cache' \
-H 'content-type: application/x-www-form-urlencoded' \

kaa update configuration using REST API

I used kaa rest api for changing my configuration as follow:
curl -v -S -u devuser:devuser123 -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' -d '{
"applicationId": "2",
"schemaId": "65539",
"endpointGroupId": "32768",
"body": "{\"timeConfig\":{\"org.kaaproject.configuration.unchangedT\":\"unchanged\"},\"dailySchedules\":{\"org.kaaproject.configuration.unchangedT\":\"unchanged\"},\"enabled\":{\"boolean":false},\"relays\":{\"array\":[false,false,false,true,true,false,false,false]},\"samplePeriod\":{\"int\":9}}",
}' 'http://localhost:8080/kaaAdmin/rest/api/configuration' | python -mjson.tool
But I get HTTP/1.1 400 Bad Request. Does my post parameters seems OK? any suggestion will be appreciated.
Finally I found the problem. Kaa Rest API Works perfect. It was about mismatching schemaID and endpointgroupId. I got the correct values from kaa web interface:
http://localhost:8080/kaaAdmin/#config:appId=2&endGroupId=32768&create=false&active=true&random=0.19035219790078206&schemaId=65539
. since the 400 ERROR CODE is not present in Rest documentation, I had no clue that where was the problem.

Couchbase create document fails through sync-gateway public rest API

As per Couchbase Sync-Gateway REST API documentation here below mentioned cURL should create a document in the specified database.
Below is the generated cURL from Postman.
curl -X PUT -H "Cache-Control: no-cache" -H "Postman-Token: 498d0fb6-77ac-9335-2379-14258c6731c7" -d '' "http://192.168.244.174:4984/db/"
I also tried adding JSON to the body of the request.
But when I send the put request through Postman, instead of creating a new document, it tries to create a new database and the JSON response is
{
"error": "Precondition Failed",
"reason": "Database already exists"
}
Am I missing something or it was a bug? Is there any other way to create a document to sync gateway?
There is a mistake in the documentation.
As per documentation,
You can either specify the document ID by including the _id object in the request message body, or let the software generate an ID.
But Couchbase REST API does not seem to work like that (may be they are not updating their documentation regularly). You need to provide the id in the URL like /{db}/{id}.
The below cURL worked for me.
curl -X PUT -H "Content-Type: application/json" -H "Cache-Control: no-cache" -H "Postman-Token: 75ab844e-5130-708e-69e9-e87f878108b4" -d '{"name": "xxx",
"full_name": "xxx yyy"}' "http://192.168.244.174:4984/db/123"
JSON response is
{
"id": "123",
"ok": true,
"rev": "1-9324dabc947fc963a754b113d1215ac3"
}