Evaluate JSON Path Expression Assertion, Special Character Issue

[Ozgur Anil Demir]

Hello, 

I have an issue about evaluate JSON Path Expression Assertion when the message includes ' character.

Sometimes it changes the ' character to \u2019

I've  added the sample request text file and two different screenshots about the issue.

At the first one it works OK,


 

The wrong result on the second one,

Do you have any suggestion to fix that?

Best regards,

Anıl

Attachment(s)

request.txt   101 B 1 version

[Joseph Fry]

Anil,

You are returning two very different things in your screenshots.

In the first screenshot you are asking for a value, in the second screenshot you are asking it to return a JSON Object.  It looks like the gateway is automatically decoding when you return a value, but not when you return an object.  I am not sure if that's a result of policy manager supporting unicode, or an extra step taken by the assertion to decode values.

The "right single quotation mark" is a unicode symbol, JSON uses UTF-8, so it has to encode the UTF-16 value. I suspect you pasted in your test input from MS Word, or some other pretty-print text editor?  If you replaced the "right single quotation mark" with its simple ASCII apostrophe (') equivalent , does it work?

[Ozgur Anil Demir]

Hi Joseph,

Yes, the situation is exactly as you described.

I actually noticed this issue when we saw an unexpected message in the backend. Afterwards, when I examined the logs on layer7, I saw that the right single quotation mark in the request was causing the problem.
It seems that the other institution's mobile application uses the right single quotation mark instead of apostrophe.

I didn't encounter any issues for ASCII apostrophe when I tested it. However, since the application does not belong to us, we cannot recommend it as a solution.

I guess the only solution in this case is to replace the right single quotation mark with apostrophe in the request with Evaluate Regular Expression Assertion, right?

[Joseph Fry]

Anil,

Replacing the offending character is certainly an option; assuming that it doesn't break their application.

Alternatively, you could determine why your getting errors with the encoded character elsewhere and make that code compatible with it.  This might save you if the application ever sends other UTF-16 characters that aren't so easily replaced.

Encoding characters in JSON is part of the JSON RFC, so the mobile application is not doing anything wrong: per https://www.ietf.org/rfc/rfc4627.txt:

2.5.  Strings

   The representation of strings is similar to conventions used in the C
   family of programming languages.  A string begins and ends with
   quotation marks.  All Unicode characters may be placed within the
   quotation marks except for the characters that must be escaped:
   quotation mark, reverse solidus, and the control characters (U+0000
   through U+001F).

   Any character may be escaped.  If the character is in the Basic
   Multilingual Plane (U+0000 through U+FFFF), then it may be
   represented as a six-character sequence: a reverse solidus, followed
   by the lowercase letter u, followed by four hexadecimal digits that
   encode the character's code point.  The hexadecimal letters A though
   F can be upper or lowercase.  So, for example, a string containing
   only a single reverse solidus character may be represented as
   "\u005C".

I think it better to support valid JSON, than to go down a sticky slope of modifying the request data.  You may find yourself playing a game of whack-a-mole.

[Ozgur Anil Demir]

Thank you for your support Joseph