Forum Discussion

Pabe1975's avatar
Pabe1975
Occasional Contributor
5 years ago

Response message automatically encoded to base64

Hi All;   I wonder if someone came across this issue and has a way to solve it. I am getting an valid SOAP response from the service and that does not have a CDATA section in it. When receiving it ...
  • Pabe1975's avatar
    Pabe1975
    5 years ago

    This is the correct solution:

     

    Add the RequestFilter.afterRequest event handler with this string to decode the response - 

    def encodedResp = context.httpResponse.responseContent
    def decodedResp = encodedResp.decodeBase64()
    String toText = new String (decodedResp)
    context.httpResponse.responseContent = toText

    The script will be executed on receiving each response, and you will see the decoded response content in the XML, Outline and Overview tabs.
    In this article, you will find more details about handling events - https://support.smartbear.com/readyapi/docs/testing/handling-events.html

richie's avatar
richie
Community Hero

Hi Pabe1975 

 

Ive never used nJAMS before - but you're saying that when publishing a message via nJAMS - you get an uncompressed/decoded response - but when you make the same request in ReadyAPI! - you're response is base64 encoded?

 

You mention you haven't got a CDATA wrapper in your SOAP response - but i dont understand the significance of you mentioning this other than to emphasise the response is being correctly read in by the ReadyAPI! xml parser.

 

whats the Congent-Type header associated with the response?  if ReadyAPI! is receiving the response compressed and encoded, Id expect the type to be maybe gzipped (so this proves ReadyAPI! isnt altering the response)

 

 

Ok - I normally do this with Postman and ReadyAPI! when trying to diagnose this sort of thing but the nJAMS will do fine.  

 

Run Fiddler (to proxy your requests)

Publish the message via nJAMS (ensuring the request is proxied via Fiddler)

Publish the message via ReadyAPI! (ensuring the request is proxied via Fiddler)

 

 

you need to try and determine the cause of the compression/decode so it makes sense if you compare the RAW requests against the RAW responses to check the differences.  Fiddler allows you to do this.  There could be an additional header in the request determining the behaviour, etc., .etc.

 

re: the Compression Limit editable field - have you tried putting a negative integer into the field? - I know the help innfo is a little thin in regards to allowed values in the fields - but II kinda remember someone suggesting sticking a negative integer into the chunking option field to disable - this might also work on the wsdl's Compression Limit field?

 

cheers,

 

rich

  • Pabe1975's avatar
    Pabe1975
    Occasional Contributor
    5 years ago

    Dear Tanya.. will try that. thanks

    • Pabe1975's avatar
      Pabe1975
      Occasional Contributor
      5 years ago

      Dear Tanya, Richie;

       

      The issue is also present in Readyapi 3.0, just tested it. 

       

      In Fiddler the message also shows as base64 encoded.  So far no solution yet. Need to check some things with developers.

      • TanyaYatskovska's avatar
        TanyaYatskovska
        SmartBear Alumni (Retired)
        5 years ago

        Thanks for checking this.

        I cannot tell you for sure if a response should be encoded automatically. I recommend that you contact our ReadyAPI Support team to investigate this. You can reach out to them here: https://support.smartbear.com/message/?prod=readyapi

         

        Please post here an update once the solution is found