Forum Discussion

Pabe1975's avatar
Pabe1975
Occasional Contributor
5 years ago
Solved

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

Hi Richie;

 

Unfortunately the -1 value did not resolve my problem. Channeling through fiddler is something I still need to set up. The weird thing is that is the first service of which the response is auto-encoded to base64. It does not seem to have any relation to the size of the response returned as far as I can see. Will let everyone know when I found the solution via Fiddler as it might help others with similar problems.

 

The reason I mentioned the CDATA because it is referred to in deh Smartbear documentation.