We use SoapUI for many interfaces in our team project. We came across a problem with german special signs, called umlauts. When sending a POST request with Json body and a german umlaut, the we get com.fasterxml.jackson.databind.JsonMappingException. It cannot be parsed with com.fasterxml.jackson.databind.ObjectMapper.
But when sending the same request using POSTMAN, then it works like a charm.
We use #Consumes({MediaType.APPLICATION_JSON + "; charset=utf-8"}) annotations and Content-Type: application/json; charset=utf-8 header. But still no effect. Has anyone ever came across such a problem or know how to solve it? We cannot change the testing tool.
In SoapUI there is an additional property for setting the encoding of your request.
It is available under the tab Request Properties.
Property: Encoding, Value: UTF-8.
Setting it as above solved our problem.
Related
I'm having an architecture that looks like that on AWS, if it matters to the issue:
Lambda function - API Gateway
I'm testing my API with postman by calling my API with a raw body of application/json type.
But in my lambda, the body looks like this
body: '{
\n\t"name": "Coinche",
\n\t"description": "Un jeu intéressant à plusieurs",
\n\t"rules": "Gagner",
\n\t"origin": "France"\n
}'
which gives me an error, obviously.
So what's the catch here? Doesn't the application/json takes care of sending a json? Should I translate the string back to json inside lambda function?
You may require to add Content-Type: application/json on API Gateway Integration Request body template mapping like this:
This is not exactly an answer to the question, but for me, none of this resolved the issues of getting \n\t added to my JSON. JSON.parse and JSON.stringify all failed with this and I could not get past the errors being thrown.
I switched from using Postman to Insomnia and problem went away. I also noticed it uses end-to-end encryption so I'm not trying to bother with variables in the same way for my keys etc..
I just have a JSON file with all my variables to re-use in Insomnia. Works pretty nicely so far.
I'm not trying to sell anything here, it is just that it took me a while to even figure out what was going on and that the issue was coming from Postman, so it seemed worth sharing.
I had the exact same experience but in a different environment.
Under the same server program from desktop windows 10 and mac, postman with windows 10 worked and the one with mac didn't work like yours.
The key "Content-Type" in Headers (refer to the below image) were both unchecked, but once I checked it on mac, it just became normal.
postman menu
So I am reading a JSON file on a remote server via standard node http.get. This JSON contains strings like this: NÖM Portionsbutter PG=20g 100er, but on my server this same string looks like this: N�M Portionsbutter PG=20g 100er.
The problem, I think, lies in the discrepancy between the header of the http request (content-type: text/plain;charset=UTF-8) and the actual encoding of the JSON file (ISO-8859-1).
I tried several versions of fixing this, like using iconv-lite's iconv.decode(data, 'latin1'), but again, these special chars ("Umlaute" in German) show up wrong.
Fun fact: Downloading the file via the browser, inspecting it via file -I file.json and getting text/plain; charset=iso-8859-1 and then using iconv.decode(data, 'latin1') works perfectly fine and the Umlaute are correct.
I am out of ideas right here ... what is the perfect way to properly parse a JSON file like this?
If the server uses an incorrect encoding, it's broken and should be fixed.
(It should use application/json, in which case the charset parameter is undefined/unused).
#Julian Reschke is obviously right but I found a way around this and am now able to read the json with all its Umlaute in it properly.
What I did is use request's encoding option and set it to null, so request is not trying to "parse" the response in any way. I then use iconv.decode(data, 'latin1') to set the proper encoding of the day and then JSON.parse it. works beautifully!
I am trying to publish a json message using the Amazonsns connector in WSO2 ESB 4.9. I am able to successfully publish a simple string message however when I set the messagestructure to json in order to send different messages to different platforms and attempting to send json as the value of message it will not work. I am using a simple transaction that looks almost exactly like the documentation sample. My Transaction:
content-type: application/json;charset=UTF-8
{
"region":"us-west-2",
"accessKeyId":"MyAccessKey",
"secretAccessKey":"MySecretAccessKey",
"version":"",
"messageStructure":"json",
"subject":"Test",
"message": {"default":"mess","email":"message"},
"targetArn":"arn:aws:sns:us-west-2:977102061874:endpoint/APNS_SANDBOX/mobile_iOS_Sandbox/34ed4324e6-1119-67sd-b7dd-f413c88e4e25",
"topicArn":""
}
My result is an unexpected error sending message out.
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,73]Message: Illegal character: <d>
My service is also like the example:
<amazonsns.init>
<region>{$ctx:region}</region>
<accessKeyId>{$ctx:accessKeyId}</accessKeyId>
<secretAccessKey>{$ctx:secretAccessKey}</secretAccessKey>
<version>{$ctx:version}</version>
</amazonsns.init>
<amazonsns.publish>
<message>{$ctx:message}</message>
<subject>{$ctx:subject}</subject>
<messageStructure>{$ctx:messageStructure}</messageStructure>
<topicArn>{$ctx:topicArn}</topicArn>
<targetArn>{$ctx:targetArn}</targetArn>
</amazonsns.publish>
I did not expect much success but just started trying different things....I attempted xml encoding the json message and get the same message on '&'. Using wire logs I found the content type of the successful messages going to Amazon were application/x-www-form-urlencoded so I also tried url encoding and get same message on the '%'.
I'm running out of ideas. I double checked the connector documentation to make sure I did not miss anything. It does say you can use a JSON transaction for Publish and gives a sample transaction however it does not discuss anything special/different that you would need to set up in order to make this work. Is there something I am missing?
UPDATE: Can see it is using the Builder for application/x-www-form-urlencoded which is stumbling on the json. Have tried setting messageType and ContentType properties to application/json. JSON Builder is enabled. It just seems the connector wants to send it out as application/x-www-form-urlencoded, is there something I am not setting properly to tell the connector this is JSON?
UPDATE: The publish template that comes with the connector is setting the messagetype to applicaiton/x-www-form-urlencoded which is overriding any of the settings I am making in my proxy service. Going to look at changing the template in the connector to use a different messagetype and/or allow me to set it in the proxy dynamically then will be trying again.
Joe
We have created a public JIRA for this issue. Please follow that.
You need to enable message builders for the content types you are sending. make sure following is done.
Enable relevent Message builder for each content-type.
< messageBuilder contentType="application/json"
class="org.apache.synapse.commons.json.JsonStreamBuilder"/>
Make sure Content-Type header property is parsing with the message.
Make sure your Json is wellformed.
Can anyone tell me if it is possible to specify mime-type returned from a RESTful web service through the URL? I am trying to demo a simple service that I created to someone and I am just using a web browser (Chrome) to invoke the service. I am trying things like this:
http://localhost:8088/providers?mimeType={application/json}
http://localhost:8088/providers?mimeType=application/json
http://localhost:8088/providers?mimeType=json
None of these work for me - I just keep getting XML returned no matter what I select.
I found several posts related to this subject, but nothing with an answer about how to do this through a URL (I found some which talked about setting headers, but I am using a browser and don't have the ability to specify headers). I found this post:
REST Content-Type: Should it be based on extension or Accept header?
And that post linked to this: http://www.xml.com/pub/a/2004/08/11/rest.html
On the xml.com site, I found this text:
URI-Specified Representation [PS, AR]
A client can specify the representation using the following query string:
mimeType={mime-type}
A REST server should support this query.
So it seems that what I am trying to do should be possible, but I can't figure out how to make it work. Can anyone help?
Thanks.
To define the headers added to your request, you can use a Chrome extension like Postman.
Then you will be able to specify an Accept header to tell Talend to return json:
Accept: Application/json
I'm struggling with creating POST multipart/mixed request with Postman Chrome extension
Here is my curl request what works nice
curl -H "Content-Type: multipart/mixed"
-F "metadata=#simple_json.json; type=application/json "
-F "content=#1.jpg; type=image/jpg" -X POST http://my/api/item -i -v
interesting part of response
Content-Length: 41557
Expect: 100-continue
Content-Type: multipart/mixed; boundary=----------------------------8aaca457e117
additional stuff not fine transfer.c:1037: 0 0
HTTP 1.1 or later with persistent connection, pipelining supported
And when I use Postman
I getting such response
{"message":"Could not parse multipart servlet request;
nested exception is org.apache.commons.fileupload.FileUploadException:
the request was rejected because no multipart boundary was
found","type":"error","status":500,"requestId":"1861eloo6fpio"}
That's it - I wish to get rid of that error.
If some more information needed please ask :)
I was facing this problem too. Short answer: remove the Content-Type header from your Postman request.
The long story is that the Content-Type for a multipart request should be rather special -- it should look kind of like this:
multipart/form-data; boundary=----WebKitFormBoundaryzeZR8KqAYJyI2jPL
The problem is that the boundary is important and it needs to exactly match the boundary used to separate the files being uploaded. The solution is simple: do not specify a Content-Type! When you upload files, Postman will automatically append the above content type for you, except the boundary will be filled in with whatever Postman or Chrome is using to separate the multipart content.
You can verify this behavior by using Chrome developer tools (within Postman) to examine the Content-Type header being added, in addition to the Content-Disposition headers of the multipart data, which are also a pain to construct manually (and impossible within Postman).
Note: My answer is a solution for those who need a multipart/form-data answer. The OP was looking for a multipart/mixed solution. My answer will not suffice in this scenario. That being said, it seems a lot of people just want the multipart/form-data solution, so I will leave my answer here.
Left this comment on: https://github.com/postmanlabs/postman-app-support/issues/1104
Ninja update: Not sure if this will help anyone else but there is a workaround for a specific scenario where you have multiple file types / content types being uploaded in a single multipart POST request.
Set the Header Content-Type to multipart/mixed.
Select the form-data option in Body.
Convert all of your items into files. String content should become a text file, etc.
Add each file by selecting file, adding a key name.
This approach doesn't require actually manually specifying each Content-Type or Content-Disposition. The trick here was to serialize all relevant content into a persistent file type. You can ignore the "convert it into a file" step if it's text :) Hope that helps someone!