Forum Discussion

Pabe1975's avatar
Pabe1975
Occasional Contributor
6 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 in ReadyApi (2.60) the response is automatically encoded to base64. This does not happen for other services I am using and when debugging the message in NJams I get a normal response from the service.

 

Of course I have looked into the base64 encoding option that is in the settings of ReadyApi and the compression limit setting is empty. I have tried putting in a large value so the message falls within the limit set in the option (so it is not encoded). 

 

Hopefully someone can give me a hand. 

 

Thanks in advance !

 

Paul

  • MisterB's avatar
    MisterB
    3 years ago

    Unfortunately this is a gap in the reporting and dashboard features - we can't currently use variables for things like today, start of week, etc..  I've worked around this problem in the past by changing the URL (which contains all report logic and therefore he date parameter) but I am considering using bookmarklets with some scripting as a more elegant solution while we wait for SmartBear to implement this feature.

9 Replies

Sort By
  • richie's avatar
    richie
    Community Hero
    6 years ago

    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
        6 years ago

        Dear Tanya.. will try that. thanks

    • Pabe1975's avatar
      Pabe1975
      Occasional Contributor
      6 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.