Gatling 2.1.6 different response body when adding substring check

Gatling (Open-Source)
1 
Hello,



In our communication we use cryptographic message syntax. When i received signed message from server

response body bytes contain content + signature + public certificate. 

I use transformResponse to verify signature and extract signed context.

Everything works fine until i add check substring to verify extracted content.

Before adding check substring i receive body as InputStreamResponseBody ( that contain actual bytes send from server)

After adding check substring i receive as StringResponseBody ( different bytes then send by server)



I have found a comment that transforming response is done before handling check, but in my case adding check 

influence response transformation. Is there a way that i can always receive  InputStreamResponseBody in transformResponse?

Is there any other way to work around this issue?



http(name).post("").headers(headers).body(body).transformResponse({
 case response: Response =>
  if (respToBoolean(response)) new ResponseWrapper(response) {
   override val body = {
    response.body match {
     case stringBody: StringResponseBody => {
      println("String response body detected !!!!")
      response.body
     }
     case _ =>
      val responseBytes: Array[Byte] = response.body.bytes
      val responseValue: String = new String(cmsModule.decodeSigned(responseBytes), "UTF-8")
      println("response value: " + responseValue)
      println("Response body class: " +response.body.getClass.getName)
      new ByteArrayResponseBody(cmsModule.decodeSigned(responseBytes), StandardCharsets.UTF_8)
    }
   }
  }
  else response
}).check(status.is(200))
2

Hi,

Like regex, css, and the likes, substring obviously deals with chars, not bytes.
As soon as you set such check, the response is expected to be valid chars for the char encoding you’re using (UTF-8 by default) and Gatling stores the String (i.e. decoded chars) and discards the byte chunks.

If you still want the response bytes, you get the String encoded bytes, not the original binary payload. Honestly, this use case shouldn’t happen.

Here, obviously, there’s some non-UTF-8 chars in your payload (as expected from an encrypted payload) that get destructed in the bytes->chars->bytes roundtrip.

Don’t use char based checks when you’re dealing with a binary payload, it just doesn’t make sense.

3

Thanks for fast response.

I thought that since I transform binary payload to chars, all char base check can be used.
What was the reason behind expectation that original response has to be valid char?
All checks are done on transformed response shouldn’t be expected that transformed response has to be valid char?

4

OK, get it.
You’re right, when there’s a transformer, we can’t assume anything about the original payload. Fixing.

5

Actually, the response is only considered as text if the Content-Type header explicitly says so (e.g. text.html or application/json).
Could you please check the response Content-Type?

6

@Leszek: We’re about to release 2.1.7, so please provide feedback. Otherwise, if it’s really an issue, you’ll miss the chance to get it fixed and released for a while :frowning:

7

I am very sorry that i have not write sooner. I had received other task that i had to take care of immediately.
I have just tested your solution to change content-type and it worked.
As it turned out my server did not switched content type when sending signed or encrypted data.
Now when sending binary payload i set content type application/octet-stream and substring check work
after transforming data to chars.

Thanks a lot for your help.

8

Great that the only sane explanation was bull’s eye :slight_smile:
Thanks for your feedback.