Server return different response from database on window and linux

Question

I have a database(MySql) hosted in Linux server on cloud. And my Java application deployed on same server. I have data in database which i am displaying in my html.

When i hit the API from application hosted on LINUX server i get junk characters like(|��59��6��20��) in the response body.

And when i connect my local application in intellij to the same LINUX database i am getting proper response response from my local application in postman(|毓59年6月20日缸). My response actually contains Japanese character.

What i have tried?

Change char set in browser.
Encode the String in java using UTF-8 charset.

In both the response from local machine and LINUX response headers are same. Only Response body differs. I have no idea what the actual issue is.

My sample code is below. I cannot post actual code here.

@Autowired
    private EncryptionService encryptionService;

    @Autowired
    private IdentifierRepository identifierRepository;

    private ApplicantRepository applicantRepository;

    @GetMapping("applicant/{applicantId}/identifier/{identifierId}")
    public ResponseEntity<Identifier> getIdentifier(@PathVariable long applicantId,@PathVariable long identifierId){
        Identifier identifier = identifierRepository.findIdentifierById(identifierId);
        identifier.setOcrResponse(encryptionService.decrypt(identifier.setOcrResponse()));
        return ResponseEntity.ok(identifier);
    }
    @PostMapping("applicant/{applicantId}/identifier")
    public ResponseEntity<Identifier> callbackUrl(@RequestBody Map<String,String> map,@PathVariable long applicantId){
        Identifier identifier = new Identifier();
        identifier.setApplicant(applicantRepository.findById(applicantId));
        identifier.setOcrResponse(encryptionService.encrypt(map.get("abbyOcr")));
        identifierRepository.save(identifier);
        ResponseEntity.noContent();
    }

Actually we are getting response as a callback from abby ocr and saving it to db after encryption.

These are the request headers.

Accept: application/json, text/plain, */*
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,hi;q=0.8
accessToken: 272f8807-f6c9-4bc4-9ba4-8082532e9364
Cache-Control: no-cache
Connection: keep-alive
Host: 10.132.214.204:8191
Origin: http://10.132.214.204:8080
Pragma: no-cache
Referer: http://10.132.214.204:8080/dob/
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36

and these are the response header from linux

Access-Control-Allow-Origin: *
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Content-Type: application/json;charset=UTF-8
Date: Wed, 20 Nov 2019 11:52:24 GMT
Expires: 0
Pragma: no-cache
Set-Cookie: JSESSIONID=174FB7AF3BC28922D3169DE1BB12612E; Path=/; HttpOnly
Transfer-Encoding: chunked
Vary: Origin
Vary: Access-Control-Request-Method
Vary: Access-Control-Request-Headers
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block

Anybody please suggest me how resolve this issue

Are you sure the response body really differs? Or just how it is being displayed (by your client/terminal/app)? — Thilo, Nov 20 '19 at 11:35
Actually these are displayed differently on postman as well as in html. — Vikram Singh, Nov 20 '19 at 11:37
Then it looks to be a client-side problem. Probably compounded by the response header (or HTML meta tags) not specifying the correct encoding, so that the client application has to guess. — Thilo, Nov 20 '19 at 11:39
Please show the relevant code and state the exact problem or error. A description alone is not enough. Also see [How to create a Minimal, Complete, and Verifiable example](http://stackoverflow.com/help/mcve). — jww, Nov 20 '19 at 11:40
@VikramSingh Does the request contain a "Accept-Charset" header? Something like: "Accept-Charset: utf-8, iso-8859-1;q=0.5"? — Zaki, Nov 20 '19 at 11:40
@Thilo I already mentioned that Response headers are same in both the case. — Vikram Singh, Nov 20 '19 at 11:41
Same in both cases could still mean incorrect in both cases (and the clever client Postman compensating for it). — Thilo, Nov 20 '19 at 11:42
Tell us what the Response headers are. Tell us if and how you produce the response body to match what those headers say. — Thilo, Nov 20 '19 at 11:44
@jww I cannot display the code here because it is confidential. One more thing i want to mention is that we are encrypting the text in database while saving. — Vikram Singh, Nov 20 '19 at 11:51
@Zaki i have updated the question and added request and response headers. — Vikram Singh, Nov 20 '19 at 11:56
@VikramSingh Try adding in a `Accept-Charset: utf-8, iso-8859-1;q=0.5, *;q=0.1` header in the request & see if the response is any different. Otherwise, we're gonna have to look at relevant bits of the server code generating the json that is being returned to the client. — Zaki, Nov 20 '19 at 12:09
If you can't provide the code or a [Minimal, Complete, and Verifiable example](http://stackoverflow.com/help/mcve), then how do you expect someone to help you? — jww, Nov 20 '19 at 12:23
See "black diamond" in https://stackoverflow.com/questions/38363566/trouble-with-utf8-characters-what-i-see-is-not-what-i-stored And if expecting to store Chinese characters, be sure to user `CHARACTER SET utf8mb4`, not `utf8`. — Rick James, Nov 22 '19 at 02:11

Tarun · Answer 1 · 2019-11-20T11:32:51.790

0

You have to set the encoding.
Try using encoding technique UTF-8 for response.

edited Nov 20 '19 at 11:32

answered Nov 20 '19 at 11:24

Tarun

986
6
19

1

No it is not related to client machine because i am getting different response in postman also. – Vikram Singh Nov 20 '19 at 11:25
1

I have to agree with the suggestion. Do you have other components on the communication channel that could use different encoding ? Could be a context, a runtime, or some other containers even if they live in the same process. – Nicolae Petridean Nov 20 '19 at 11:52
No it is a direct call to service – Vikram Singh Nov 20 '19 at 11:57
can you try to check what is inside your client ? I mean probably it tries to decode the response with the wrong encoding, which is somewhere decoded. In debug at runtime you should be able to see it. When the message gets reconstructed. From the headers I see you do not specify any Accept-charset header. you can also try to setup that one. Depending on how your client is taking that onto consideration. – Nicolae Petridean Nov 20 '19 at 12:43
my client is browser it do what ever it does. But my code is not doing any decoding. – Vikram Singh Nov 20 '19 at 13:17

Server return different response from database on window and linux

1 Answers1