I'm writing a c++ websocket server, dev tools on chrome says sec-websocket-accept header value is incorrect. I've tested for days and it all seems fine. The client closes with readystate 3 without the websocket onopen being called although it shows as 101 in chrome dev tools.
This is my code for calculating the keys
string magickey = "258EAFA5-E914-47DA-95CA-C5AB0DC85B11";
string key = msgkey.append(magickey);
unsigned char* sha_str = SHA1(reinterpret_cast<const unsigned char*>(key.c_str()), key.length(), nullptr);
string acceptkey = base64_encode(reinterpret_cast<const unsigned char*>(sha_str), strlen((char*)sha_str));
string handshake_response = "HTTP/1.1 101 Switching Protocols\r\n";
handshake_response.append("Upgrade: websocket\r\n");
handshake_response.append("Connection: Upgrade\r\n");
handshake_response.append("Sec-WebSocket-Accept: "+acceptkey+"\r\n");
handshake_response.append("\r\n");
Chrome Response
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: 5T5MvxP1iz40vLpi3kQs/ifDaCo=
Chrome Request
GET ws://localhost:4897/echo HTTP/1.1
Host: localhost:4897
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Origin: http://localhost
Sec-WebSocket-Version: 13
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Sec-WebSocket-Key: LKF8lHGznbKGIgO1UzAOhg==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
It says "Error during WebSocket handshake: Incorrect 'Sec-WebSocket-Accept' header value".
Chrome also shows one additional frame received size 79 bytes opcode -1.
Thanks Heaps!
Chrome says that 'Sec-WebSocket-Accept' is incorrect. Trying to compute it manually, I have to agree with Chrome.
My test:
concat "LKF8lHGznbKGIgO1UzAOhg==" and "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"
=> "LKF8lHGznbKGIgO1UzAOhg==258EAFA5-E914-47DA-95CA-C5AB0DC85B11", that's key.
compute SHA1 160 bits hex: bf15 14e3 7108 0ee4 7782 c709 a767 cc72 423d e5c4
From your log, your encoding to base64 is: 5T5MvxP1iz40vLpi3kQs/ifDaCo=
Decoding it to hex: e53e 4cbf 13f5 8b3e 34bc ba62 de44 2cfe
27c3 682a
The bold values should be equal. Feel free to correct me if I'm wrong somewhere.
Possible problems:
Is sha_str null-terminated ? i.e. strlen((char*)sha_str) == 20 ?
signed/unsigned char mixup ?
Related
I'm using zapworks studio to develop an AR experience. It uses Z.ajax to make the ajax calls. I make a GET request and a POST request. I'm also using smileupps to host couchdb(they have free hosting). Here's the CORS configuration:
credentials: false; headers:Accept, Authorization, Content-Type, Origin;
methods: GET,POST,PUT,DELETE,OPTIONS,HEAD; origins: *
Everything works fine when launching ZapWorks Studio on windows. When scanning the zapcode with an android device, however, the post ajax call fails. Only the post. I am using basic authentication. I enforce that only the admin can manage the database on couchdb. I can access the host from both the desktop and the phone from a web browser to do everything manually.
I tried everything I could of to solve the problem: remove authentication, change the CORS configuration...nothing works. I thought it was an issue with CORS but everything works fine on windows and on the mobile just the POST fails...I keep getting a status code of 0.
EDIT - New info, testing on apitester also works on the desktop and mobile.
EDIT - Here's the zpp to show the logic
EDIT - Tried with REST Api Client on my phone and it worked as well. This can only be a CORS issue or something with zapworks. Weird that it works on windows but not on the phone.
EDIT - I found out what the problem is, but not how to fix it. So I set a proxy to debug the requests made from zapworks studio following this tutorial. It seems that it does a preflight request but gets the response
"HTTP/1.1 405 Method Not Allowed"
even though the payload is
{"error":"method_not_allowed","reason":"Only DELETE,GET,HEAD,POST
allowed"}.
Here's the request:
OPTIONS /ranking HTTP/1.1
Host: somehost.com
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: null
User-Agent: Mozilla/5.0 (Linux; Android 8.0.0; SM-G950U1 Build/R16NW; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/67.0.3396.87 Mobile Safari/537.36
Access-Control-Request-Headers: authorization,content-type,x-requested-with
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-US
X-Requested-With: com.zappar.Zappar
and the response:
HTTP/1.1 405 Method Not Allowed
Server: CouchDB/1.6.0 (Erlang OTP/R15B01)
Date: Mon, 18 Jun 2018 21:22:12 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 76
Cache-Control: must-revalidate
Allow: DELETE,GET,HEAD,POST
Access-Control-Expose-Headers: Cache-Control, Content-Type, Server
Access-Control-Allow-Origin: null
Connection: keep-alive
{"error":"method_not_allowed","reason":"Only DELETE,GET,HEAD,POST allowed"}
which clearly shows that POST is allowed...
On the windows side, there doesn't seem to be a preflight request for some reason and my guess is that's why it works. Now the question is how do I configure CORS on couchdb to work on android. These are the configurations available:
enable_cors: true
credentials: false
headers:Accept, Authorization, Content-Type, Origin
methods:GET,POST,PUT,DELETE,OPTIONS,HEAD
origins:*
This is the code:
const Open_SansRegular_ttf0 = symbol.nodes.Open_SansRegular_ttf0;
parent.on("ready", () => {
const Plane0 = symbol.nodes.Plane0;
let ajaxParameters : Z.Ajax.Parameters = {
url: "https://something.smileupps.com/test/_all_docs?include_docs=true",
headers: {"Authorization": "Basic my64encoding"},
method: "GET",
timeout: 3000
};
// Perform the AJAX request
Z.ajax(ajaxParameters, (statusCode, data, request) => {checkRequest(statusCode, data);});
ajaxParameters = {
url: "https://something.smileupps.com/test",
headers: {"Content-Type":"application/json", "Authorization": "Basic my64encoding"},
method: "POST",
body: '{"name" : "asdasd", "something": 234}',
timeout: 3000
};
Z.ajax(ajaxParameters, (statusCode, data, request) => {checkRequest(statusCode, data);});
});
function checkRequest(statusCode, data) {
if (statusCode === 0) {
Open_SansRegular_ttf0.text("Unable to connect - check network connection.");
console.log("Unable to connect - check network connection.");
return;
}
if (statusCode < 200 || statusCode >= 300) {
Open_SansRegular_ttf0.text("HTTP request failed: " + statusCode);
console.log("HTTP request failed: " + statusCode);
return;
}
// Attempt to parse the data returned from the AJAX request as JSON
let parsedData;
try {
// https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse
parsedData = JSON.parse(data);
} catch (e) {
Open_SansRegular_ttf0.text("Unable to parse JSON: " + e);
console.log("Unable to parse JSON: " + e);
return;
}
return parsedData;
}
EDIT
Here's the request on windows
Accept:*/*
Accept-Encoding:gzip, deflate
Accept-Language:en-US
Authorization:Basic mybase64encoding
Connection:keep-alive
Content-Length:37
Content-Type:application/json
Host:http://something.smileupps.com/test
Origin:file://
User-Agent:Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) ZapWorksStudio/4.0.4-stable Chrome/58.0.3029.110 Electron/1.7.9 Safari/537.36
X-DevTools-Request-Id:3680.9
X-Requested-With:XMLHttpRequest
and the response:
Access-Control-Allow-Origin:file://
Access-Control-Expose-Headers:Cache-Control, Content-Type, ETag, Server
Cache-Control:must-revalidate
Content-Length:95
Content-Type:text/plain; charset=utf-8
Date:Mon, 18 Jun 2018 21:36:22 GMT
ETag:"1-512f89feb3d0a88781119e772ec6fd7b"
Location:http://something.smileupps.com/test
Server:CouchDB/1.6.0 (Erlang OTP/R15B01)
No preflight.
Your problem is in the request: Origin: null is usually what you get when the Web page containing the xhr request is opened with the file: rather than the http or https protocol. You won't get any successful CORS request with such an origin.
I am facing a rather confusing problem since the last two days. I am working on a document management system, that uses an API that pulls in data from SOLR. The data is in tune of around ~15Mbs, and pulls records of more than 4000+ documents. The API has response in this format -
{
"documents": [
{
id: 123,
some_field: "abcd",
some_other_field: "abcdef"
},
{
id: 124,
some_field: "abcd1",
some_other_field: "abcdef1"
}
]
}
Everything works fine in browser. If I hit the endpoint in Chrome or Firefox browser, it gives me the correct output and I am able to see the JSON output.
However, if I try hitting the same API endpoint with a Java or JS code - the response code is 200, but the output in console (Terminal or Eclipse) shows unicode characters like \u0089 \u0078 U+0080 - all the output comes in this way, and since there are around 4000+ records being fetched by the API, the console kinda fills with all of these unicode characters.
The only difference that I see between the requests made from browser and the code is that in browser I can see Content-Encoding : gzip, while I cannot find this header from the code that I written . For eg - in JS code, through Chakram framework, I can check
expect(response).to.be.encoded.with.gzip
mentioned here. However, this returns a failure stating expected undefined to match gzip
What am I missing here? Is this something related to encoding/decoding or something entirely different?
Edit 1 : The Response Headers as seen in Network tab of Chrome :
cache-control: max-age=0, private, must-revalidate, max-age=315360000
content-encoding: gzip
content-type: application/json; charset=utf-8
date: Tue, 22 May 2018 06:07:26 GMT
etag: "a07eb7c1eef4ab97699afc8d61fb9c5d"
expires: Fri, 19 May 2028 06:07:26 GMT
p3p: CP="NON CUR OTPi OUR NOR UNI"
server: Apache
Set-Cookie : some_cookie
status: 200 OK
strict-transport-security:
transfer-encoding: chunked
vary: Accept-Encoding
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-request-id: abceefr4-1234-acds-100b-d2bef2413r47
x-runtime: 3.213943
x-ua-compatible: chrome=1
x-xss-protection: 1; mode=block
The Request Headers as seen in Network tab of Chrome
Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Connection: keep-alive
Cookie: some_cookie
Host: abcd.bcd.com
IV_USER: demouser123
IV_USER_L: demouser123
MAIL: demouser#f.com
PERSON_ID: 123
Referer: http://abcd.bcd.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36
X-CSRF-TOKEN: some_csrf_token
Edit 2 : The tests that I am using
describe('Hits required API',()=>{
before(()=>{
return chakram.wait(api_response = chakram.get(url,options));
});
it('displayes response',()=>{
return api_response.then((t_resp)=>{
console.log(JSON.stringify(t_resp));
expect(t_resp).to.have.header('Content-Encoding','gzip');
});
});
This has nothing to do with encoding. The web server in general compresses to gzip to save the bandwidth since its redundant to transfer the whole 15MB file as is refer this article for more about gZip and the its working ( https://betterexplained.com/articles/how-to-optimize-your-site-with-gzip-compression/ ). So where does it went wrong and how it worked in chrome is pretty simple chrome has an inbuilt unicode parser(even an HTML parser) in its devTools which can show you the parsed content rather showing you the wiered text (same can be seen in response tab next to preview tab). why you see wierd text is that you are stingfying the response which will escape special character if any console.log(JSON.stringify(t_resp));. You cannot use something like console.log("response", t_resp); without stringifying in terminal since the terminal doesn't have a JSON or an unicode parser it just prints in text. try removing that console since stringifying a 15mb file is a costly process.
Edit 1:-
if you still want to output in the console here whats to be done.
Since NODE cannot decode gzip by default directly (not with chakram, its just a APItesting platform) you can use zlib to do this. Please find the example snippet
const zlib = require('zlib');
describe('Hits required API',()=>{
before(()=>{
return chakram.wait(api_response = chakram.get(url,options));
});
it('displayes response',()=>{
return api_response.then((t_resp)=>{
zlib.gunzip(t_resp, function(err, dezipped) {
console.log(dezipped);
});
});
});
Try with console.dir to display your values
describe('Hits required API',()=>{
before(()=>{
return chakram.wait(api_response = chakram.get(url,options));
});
it('displayes response',()=>{
return api_response.then((t_resp)=>{
console.dir(t_resp, { depth: null });
});
});
Console.dir
I'm making a POST request from a Chrome extension that appears identical to the one that submitting the form manually would do. I've submitted both and compared the body and headers and they seem to be identical.
The POST made via the browser form results in a 302 redirect. The POSTed entry is created and the user ends up on an edit screen for it.
The POST made via the extension results in a 500 error.
I'm filtering many of the headers sent by the extension to match those made by the browser, in case the server is looking for certain things that tip off a request as being non-native.
Hoping to exhaust all options before contacting the devs of the system being POSTed to. Any obvious things that could be happening server-side to block this request?
Here's the POST request made via the browser form:
Request Headers
Host: myhost.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded
Content-Length: 901
Referer: https://myhost.com/referer
Cookie: app2=cookieredacted
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Pragma: no-cache
Cache-Control: no-cache
Request Body
record[user_name]=aasldkjflasdjf
record[new_password]=ljl;jl;kjklj
record[first_name]=ethan
record[middle_name]
record[last_name]=lastnm
record[name_suffix]
record[gender]=M
record[dob]=07/28/77
record[ssn]=654656546
record[group_number]
record[misc_number]
record[mothers_maiden_name]
record[active]=N
record[active]=Y
record[has_paper_chart]=0
record[notes]
record[address1]=234+htha+st
record[address2]
record[city]=euge
record[county_of_residence]
record[state]=OR
record[zip]=98754
record[country]
record[tel1]=5155555555
record[tel1_status]=4
record[tel2]
record[tel2_status]
record[cell]
record[cell_status]
record[email]=ethan#foo.com
record[preferred_contact]=home_tel
record[house]
record[room]
record[bed]
record[classroom]
Response Headers
Server: nginx/1.6.2
Date: Sun, 09 Jul 2017 01:06:12 GMT
Content-Type: text/plain
Transfer-Encoding: chunked
Connection: keep-alive
Status: 302 Found
Location: /entry/edit
And from the extension:
Request Headers
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding:gzip, deflate, br
Accept-Language:en-US,en;q=0.5
Cache-Control:no-cache
Connection:keep-alive
Content-Length:920
Content-Type:application/x-www-form-urlencoded
Cookie:app2=cookieredacted; gsScrollPos-2545=
Host:myhost.com
Pragma:no-cache
Referer:https://myhost.com/referer
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.50 Safari/537.36
Request Body
new_password_stub:"FoECbiRN"
record[active]:"Y"
record[address1]:"123 N 5th St"
record[address2]:""
record[bed]:""
record[cell]:""
record[cell_status]:""
record[city]:"Eugene"
record[classroom]:""
record[country]:""
record[county_of_residence]:""
record[dob]:"9/28/91"
record[email]:"ethan#foo.com"
record[first_name]:"Foo"
record[gender]:"M"
record[group_number]:""
record[has_paper_chart]:0
record[house]:""
record[last_name]:"Bar"
record[middle_name]:""
record[misc_number]:""
record[mothers_maiden_name]:""
record[name_suffix]:""
record[new_password]:"FoECbiRN"
record[notes]:""
record[preferred_contact]:"home_tel"
record[room]:""
record[send_notifications]:0
record[ssn]:"222222222"
record[state]:"OR"
record[tel1]:"5155555555"
record[tel1_status]:2
record[tel2]:""
record[tel2_status]:""
record[user_name]:"BarFoo2017"
record[zip]:"97401"
Response Headers
Cache-Control:no-cache
Connection:keep-alive
Content-Length:5110
Content-Type:text/html; charset=utf-8
Date:Sun, 09 Jul 2017 02:09:33 GMT
Server:nginx/1.6.2
Set-Cookie:mysite_session_id=; max-age=0; expires=Thu, 01 Jan 1970 00:00:00 -0000
Status:500 Internal Server Error
Thanks to wOxxOm for this one -
The extension was posting an extra field record[send_notifications] which was causing the 500 error.
I have an endpoint in my app (endpoint A) that returns HTML/JS that should self-execute and hit another endpoint (endpoint B).
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<body>
<a id="link" href="https://myhost/mycontext/endpointB" />
<script language='javascript'>
document.getElementById('link').click();
</script>
</body>
</html>
When I launch endpoint A in Chrome/Firefox/Safari, endpoint B correctly loads in the browser on the first attempt.
In Internet Explorer 11, however, it actually fails on the first request to navigate to endpoint B, and then inexplicably issues another request to endpoint A again. On this second request to endpoint A, it successfully executes the JavaScript and loads endpoint B.
Fiddler indicates that an 'SSLv3-compatible ClientHello handshake' was found in the second request but not in the first request. Does this imply that my first request from IE does not have a compatible handshake for some reason? What would cause this? Is this a consequence of issuing the request from self-executing JavaScript?
Request 1 (Does not successfully launch endpoint B)
CONNECT myhost:443 HTTP/1.0
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Connection: Keep-Alive
Content-Length: 0
Host: myhost
Pragma: no-cache
After the client received notice of the established CONNECT, it failed to send any data.
Response 1 (no body)
HTTP/1.0 200 Connection Established
FiddlerGateway: Direct
StartTime: 11:37:20.457
Connection: close
Request 2 (Successfully launches endpoint B)
CONNECT myhost:443 HTTP/1.0
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Connection: Keep-Alive
Content-Length: 0
Host: myhost
Pragma: no-cache
A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.
Version: 3.3 (TLS/1.2)
Random: 57 8F A8 C0 C7 95 85 02 77 14 1F 10 FD 10 D6 1E 67 2A DA F1 F6 27 22 45 55 FA 8D 55 0B 5D 6B 21
"Time": 6/4/2072 8:23:35 AM
SessionID: empty
Extensions:
server_name myhost
status_request OCSP - Implicit Responder
elliptic_curves secp256r1 [0x17], secp384r1 [0x18]
ec_point_formats uncompressed [0x0]
signature_algs sha512_rsa, sha512_ecdsa, sha256_rsa, sha384_rsa, sha1_rsa, sha256_ecdsa, sha384_ecdsa, sha1_ecdsa, sha1_dsa
extended_master_secret empty
renegotiation_info 00
Ciphers:
[C028] TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
[C027] TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
[C014] TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
[C013] TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
[009F] TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
[009E] TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
[009D] TLS_RSA_WITH_AES_256_GCM_SHA384
[009C] TLS_RSA_WITH_AES_128_GCM_SHA256
[003D] TLS_RSA_WITH_AES_256_CBC_SHA256
[003C] TLS_RSA_WITH_AES_128_CBC_SHA256
[0035] TLS_RSA_AES_256_SHA
[002F] TLS_RSA_AES_128_SHA
[C02C] TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
[C02B] TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
[C024] TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
[C023] TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
[C00A] TLS1_CK_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
[C009] TLS1_CK_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
[006A] TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
[0040] TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
[0038] TLS_DHE_DSS_WITH_AES_256_SHA
[0032] TLS_DHE_DSS_WITH_AES_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
[0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA
[0005] SSL_RSA_WITH_RC4_128_SHA
[0004] SSL_RSA_WITH_RC4_128_MD5
Compression:
[00] NO_COMPRESSION
Response 2
HTTP/1.0 200 Connection Established
FiddlerGateway: Direct
StartTime: 11:37:20.493
Connection: close
Encrypted HTTPS traffic flows through this CONNECT tunnel. HTTPS Decryption is enabled in Fiddler, so decrypted sessions running in this tunnel will be shown in the Web Sessions list.
Secure Protocol: Tls12
Cipher: Aes256 256bits
Hash Algorithm: Sha384 384bits
Key Exchange: ECDHE_RSA (0xae06) 256bits
== Server Certificate ==========
[Subject]
CN=*.mycompanyname.com, OU=Secure Link SSL Wildcard, O=My Company's Name, STREET=My Address, L=My City, S=IL, PostalCode=99999, C=US
[Issuer]
CN=Network Solutions OV Server CA 2, O=Network Solutions L.L.C., L=Herndon, S=VA, C=US
[Serial Number]
Removed before posting to StackOverflow
[Not Before]
8/13/2015 7:00:00 PM
[Not After]
1/26/2017 5:59:59 PM
[Thumbprint]
Removed before posting to StackOverflow
[SubjectAltNames]
*.mywebsite.com, mywebsite.com
I'm sending utf-8 encoded text to a wso2 service bus. The service bus interprets this as unicode. In the header the encoding is specified and the character type is also set as utf-8.
When sending the µ, it gets send as C2 B5. If I check this on the utf-8 codepage its the µ sign. But the bus thinks its C2 = Â and B5 = µ.
Does anyone know how to prevent or fix this?
EDIT:
The json my client send to the WSO32
Accept: application/json, text/plain, /
Content-Type: application/json;charset=utf-8
Accept-Language: nl-BE
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0; MSAppHost/1.0)
Host: app1.o.esb.local
Content-Length: 156
Connection: Keep-Alive
Pragma: no-cache
{"meldingen":{"MeldingDto":[{"Id":-1,"Code":"","MeldingTijd":"2014-06-20T15:34:52.680+02:00","Melder":"ABW_PN","Commentaar":"testµ","InterventieId":381}]}}
Here in the hexview in fiddler the µ sign is C2 B5.
The WSO2 service sees this as 2 characters instead of one.
When I use soapUI and send the same character gets send as, B5 and that gets interpreted correctly. I would expect that the WSO2 would know how to handle UTF-8.
Should I edit my encoding to send B5 instead of C2 B5 or does the WSO2 esb need an aditional setting so it knows how to interpret the UTF8 encoding correctly?
Thanks in advance
Ian
My collegues and I figured out how to fix this. On the client we encoded the message in the following manner:
encodeURIComponent(comment);
In the case of the µ sign we got %C2%B5.
Then on the server side WSO2 we used a javascript function (local entry):
function decode(mc)
{
var Input = mc.getProperty('InputdecodeURIComponent').toString();
var Output = decodeURIComponent(Input);
mc.setProperty('OutputdecodeURIComponent', Output);
}
<property name="InputdecodeURIComponent" value=”ZET HIER ENCODED VALUE” />
<script language="js" key="HelperFunctions.js" function="decodeXml"/>
<property name="Output" expression="get-property('OutputdecodeURIComponent')"/>
I hope this helps.
Regards
Ian