Forum Discussion

mmoser18's avatar
mmoser18
Frequent Contributor
5 years ago

SOAP-UI Mock: Response in different character sets on different systems - WHY?

I have the odd case that a mock service that I defined works as intended on one system but not on another (both are Windows 10 workstations/laptops running the same version, configured with the same system language and character set and running the same Java version (AdoptOpenJDK v8.x)). On one system the payload is returned in the character set intended (UTF-16LE), on another the response is in a different character set (ISO-8891-5). Any explanation for that?

 

Background:

I need to create a REST-service mock that returns its response in an unusual character set: UTF-16LE.

 

For that I created a text-file (the name of the file is passed via a custom property) with the bitwise exact content of the intended response (i.e. saved in UTF-16LE) and I defined a scripted mock-response that reads the content of that file and returns it like so:

 

def path = context.expand('${#MockService#responseFileName}').trim()
log.info("reading data from '${path}'")
def file = new File(path)
if (file.exists() && file.isFile()) {
	byte[] fileBytes = file.bytes
	int length = fileBytes.length
	log.info("read ${length} bytes of data: '${fileBytes}'")

	String str =  new String(fileBytes, java.nio.charset.StandardCharsets.UTF_16LE)
	 mockResponse.responseContent = str
} else {
	throw new Exception("file '${path}' not found!")
}

 

 

The "Content | Media type:" defined in the response form is "text/csv; charset=UTF-16LE".

 

If I run that mock on my own laptop then the response I get from this service is EXACTLY as contained in the original file (i.e. in characters set of the response is signaled in the response header (as received by the browser and checked using FF's Web Developer tools) as "UTF-16LE" - as intended - and when saving the content to a file and comparing it to the original it is bitwise identical). This is as it should be!

 

But when the very same mock (i.e. same SOAP-UI project file and the very same input file (verified!)) runs on a colleague's laptop, then the character set signaled in the response header is "text/csv; charset=ISO-8859-1" (i.e. the header specified in the response form seems to be ignored)/overruled - why and by what?) and the content is indeed in ISO-8859-1 character set (aka. "ANSI"), i.e. different from my own laptop.

 

We are completely puzzled! Why does SOAP-UI behave so differently on two different systems? We faithfully checked all settings and preferences but we could not locate any differences. What can interfere here? What configuration controls this?

  • richie's avatar
    richie
    Community Hero
    5 years ago
    Hey,

    You mightve already confirmed this so apologies if you hVe, but have you compared the system properties of both instances?

    I.e. Help >> System Properties

    Id compare these. I know theres an emcoding/charset attribute in there somewhere that might help....

    Cheers

    Rich
    • mmoser18's avatar
      mmoser18
      Frequent Contributor
      5 years ago

      We compared our System Properties. The only - in this context - possibly relevant difference is the file.encoding setting (UTF-8 in my case and Cp1252 on my colleague's machine). But the READING from file is not the issue here. The bytes read are identical (the script displays them in the log output - see line

      log.info("read ${length} bytes of data: '${fileBytes}'"

      ... and at that point the bytes are exactly identical (i.e. identical values and correct byte ordering (according to UTF-16LE)).

       

      It must be something that affects the SENDING of the response content and thereby mangling the character encoding.

      • richie's avatar
        richie
        Community Hero
        5 years ago
        Hey mmoser18,

        I appreciate what you stated about something altering the sending of a response however a colleague had an issue that was analgous to yours, hence why i queried the default encoding.

        When you say it runs differently on two machines, how were the readyapi! projects setup on each machine? Created in one, then a copy sent to the other machine? If thats not the case then the mocks were setup independently? If yes.......

        To attempt to fix: export the project that works and import overwriting the project on the machine that doesnt work.
        If this doesnt resolve the issue, then logically the issue is not at project level, its global/workspace level and id look at the differences in system properties as surely its reasonable that this could be the cause of the issue? Unless youve got a dodgy event handler running...

        Ta

        Rich