Issue Upgrading from 2.0.3 to 2.1.1

I am seeing an issue upgrading from 2.0.3 to 2.1.1. For some reason, the request body is not being set when I am doing a POST. Here is the request I am making:

val createDocumentSeriesRequest = http(“create-document-series”)
.post(session => getApigBaseUrl() + “/services/orchestration/documentseries”)
.signatureCalculator(session => new CISignatureCalculator(session(“access-token”).as[String], session(“mac-key”).as[String]))
.check(, jsonPath("$.urid").saveAs(“document-series-urid”))

Here is what the request and response looks like in 2.0.3:

Accept: [application/json]
Content-Type: [application/json]
Referer: [https:///oauth2b/reply/2f2671ad-c617-4c2b-a3b6-edbc62691ea1?code=4dd622e5-0787-463f-8aba-0d7af31aa547]
Authorization: [MAC id=“3aa155df-b072-4759-8651-f0f6fb97894e”,ts=“1418751889”,nonce=“N0DUCI0P6R”,ext=“md5(MdaYnomNdTB6JeWjg1vinw==)”,mac=“bOlfdtNOQZnR4qMyVYiQRcqFCmY=”]
Content-MD5: [MdaYnomNdTB6JeWjg1vinw==]
cis=9c3722fd-ee6a-4f71-9e48-e2466160b2e9; domain=; path=/; expires=1450287887000; HTTPOnly
stringData={ “label”: “500kb.pdf” }

Are you sure the body is not sent?

Why I did find out is that it was not properly logged:
But it looked to me that the body was actually properly sent.


I am pretty sure it’s not being sent. The reason I am getting the 401 is because the Content-MD5 is different from what is set in the Authorization header. That’s because the Content-MD5 is generated from the payload coming in and it’s coming is as empty.

Here is another example request where I am seeing the same behavior:

val createAccountRequest = http(“create-account-request”)
.post(session => getApigBaseUrl() + “/services/orchestration/accounts”)
.signatureCalculator(session => new CISignatureCalculator(session(“access-token”).as[String], session(“mac-key”).as[String]))

Gatling 2.0.3:

HTTP request:
POST https:///services/orchestration/accounts
Accept: [application/json]
Content-Type: [application/json]
Referer: [https:///oauth2b/reply/260b86fd-873b-48fb-8b6c-790c07bbe5de?code=0769c8f1-1106-4640-a7ab-d0f42053b15f]
Authorization: [MAC id=“17ed81e1-b1ec-487f-bb78-9ee5d4e8a70e”,ts=“1418762232”,nonce=“NWP8S7CNBF”,ext=“md5(Uz4ImAqrrJwfDlD1Iv7W9g==)”,mac=“xKRMA+NZ0Znn6rRdOWKscQwoAnE=”]
Content-MD5: [Uz4ImAqrrJwfDlD1Iv7W9g==]
cis=fb4bde82-c15b-4a0f-ab84-23f84a646d3b; domain=; path=/; expires=1450298230000; HTTPOnly
“type”: “USER”,
“status”: “PERMANENT”,
“userId”: “gatling-u4hrvb8z”,
“email”: “”,
“realm”: " ",
“realmAccountId”: “12345”,
“enabled”: true,
“phones”: {},
“label”: “gatling-u4hrvb8z”

That’s because the Content-MD5 is generated from the payload coming in and it’s coming is as empty.

That’s the piece of information that was missing!

I’m pretty sure your CISignatureCalculator uses request.getStringData.
But 2.1 bring a nice performance optimization that populates request.getCompositeByteData instead. This method returns a java.util.List of Array[Byte]. Decode each one and concatenate them and you’ll get a full String.

Something like:

request.getCompositeByteData.foldLeft(new StringBuilder) { (sb, bytes) =>

sb.append(new String(sb, “UTF-8”))

Or maybe your CISignatureCalculator can make use of those bytes.

I have no words. That is amazing!

Gatling is probably the most revolutionary open source project I have ever used. We went from JMeter to this and I can’t begin to explain how much better it is. We are doing things with gatling that we couldn’t even do with JMeter.

With that being said, I wanted to thank you for developing this and spending the time to answer all the questions posted in this group. It is much appreciated!

My Scala is nowhere it needs to be to contribute but If there is anyway I can help at all please let me know: