Layer7 API Management

 View Only
  • 1.  Default Character encoding

    Posted Oct 05, 2015 11:48 AM

    Hello there,

    Is it possible to  configure default character encoding that Gateway can allow UTF-8 character encoding for all the WebServices through out the cluster? can we do same for individual WebService?


    What i'm expecting is when a special characters or Russian characters are being passed Gateway need to identify them as UTF-8 and read those accordingly.

    Any help would be appreciated



    Thanks in advance


    Message was edited by: Leif Bildoy Removed Categories for MAG

  • 2.  Re: Default Character encoding

    Broadcom Employee
    Posted Nov 18, 2015 08:09 PM

    Good evening,


    The gateway supports UTF-8 for requests which is normally identified in the HTTP Header Content-Type. You can make a listen port through the Manage Listen Port -> Port Properties -> Advanced tab use a specific content-type. Would you be able to provide an example of the message and issue you are seeing?




    Stephen Hughes

    CA Technologies
    Director, CA Support

  • 3.  Re: Default Character encoding

    Broadcom Employee
    Posted Nov 23, 2015 10:28 AM

    Hi srav,


    I do not know if this really answer your question, but you can set "ip.httpDefaultContentTyp" cluster-wide property in your gateway -> this will set a default Content-Type value if a response without this header is provided.


    Have a nice day !

  • 4.  Re: Default Character encoding
    Best Answer

    Posted Dec 09, 2015 05:43 PM

    Sorry for the delayed response folks


    We are having issue while reading the Russian characters in Gateway.

    We developed a policy in 7.1 version of Layer 7 Securespan Gateway which receives JSON and converts that to SOAP while sending it to backend.

    Unfortunately Gateway is not able to recognize the UTF-8 charset receiving in the FirstName and LastName fileds in the below messages eventhough the content type and charset is specified in the header. So Gateway is passing the junk characters to backend.

    Below is the request as sending by the consumer and the requested captured at Gateway.

    Original Request: As sending by the Consumer {"siteId": 590,"eventId": 271,"channelId": 1,"email": "","firstName":"????","lastName":"????","CommunicationOptIn": true,"programCommunicationOptIn": true,"locale":"ru_RU","termsAccepted" : true,"privacyAccepted" : true,"binNumber" : 55218625}

    Header Captured in Gateway:

    host:XXXXXXX, connection:keep-alive, content-length:295, cache-control:no-cache, origin:chrome-extension://fdmmgilgnpjigdojojpjoooidkmcomcm, us

    er-agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.85 Safari/537.36, content-type:text/plain;charset=UTF-8, accept:*/ *, accept-encoding:gzip, deflate, accept-language:en-US,en;q=0.8, cookie:_ga=GA1.2.574680444.1429203491; s_pers=%20s_vnum%3D1438443512193%2526vn%253D2%7C1438443512193%

    3B%20s_fid%3D4825D911E9AA2138-0D8212AD1C265CA4%7C1500826710730%3B%20s_getNewRepeat%3D1437668310737-Repeat%7C1440260310737%3B%20s_invisit%3Dtrue%7C1437670110741%3B; s_v i=[CS]v1|2A31C024851D2D39-40000117E0000956[CE]; WT_FPC=id=469b4a0d-ebb1-4801-8528-2c34a18bbbed:lv=1444079257732:ss=1444079256286

    Original request captured Gateway:

    {"siteId": 590,"eventId": 271,"channelId": 1,"email": "","firstName":"Ðжон","lastName":"СмиÑ","mcCommunicationOptIn": true,"programCommunicationOptIn": true,"locale":"ru_RU","termsAccepted" : true,"privacyAccepted" : true,"binNumber" : 55218625}


    Issue is due to following:

    The Apply JSON Transformation assertion is causing the observed behavior. If I add an Apply JSON Transformation to the provided message than the valid UTF-8 characters do not retain their UTF-8 encoding.

    This behavior does not appear to occur in version 8.3.00, is documented as such in the list of resolved issues: I ran my tests on version 8.3.00 and was not able to reproduce the issue at that point. This can be avoided in version 7.1 by ensuring that a charset designation is added to the Content-Type header. I was able to reproduce the observed behavior and implement the workaround successfully by setting the content type as "application/json;charset=utf-8.




  • 5.  Re: Default Character encoding

    Posted Apr 20, 2018 09:47 AM

    HI srav,


    I'm facing kind of issue where i'm getting JSON request in which  it consist of character encoded character '&', on the gateway while converting this JSON response  to SOAP its further getting encoded to '&' and going to backend, i tried decoding the JSON request but not succeeded yet, could you please  provide any suggestions. i've kept content Type as 'application/json; charset=utf-8'.