Potential bug in POST HTTPS request with formParam's for Gatling versions 3.0.0+

Gatling (Open-Source)
1

Hello there Gatling community!

I’ve been using Gatling for the last months to write component & performance tests and stumbled across this issue that made me go back to previous Gatling versions to work.

My current environment is:

  • OpenJDK Runtime Environment (Zulu 8.38.0.13-CA-win64) (build 1.8.0_212-b04)

The scenario
I am performing a POST request to a HTTPS endpoint passing some Form params with it.

Doing this with Gatling version 3.x.x.

The code looks like this:

import io.gatling.core.Predef._
import io.gatling.http.Predef._

class GetSmSessionSimulation2 extends Simulation {

  val loginChallenge =
    scenario("Get login challenge details")
      .exec(http("Login")
      .post("https://vm00006525.eu.acme.com:9100/e2e_sim")
      .formParam("sfid", "0401458997_53")
      .formParam("challenge", "0200086f5e072ab473acd40300042d04c75c040100db6013fd774d5ed20919eedf9b8376ebf68c7a7b76574590ba4dca73c9c49c28b4f38acbdf5bbf6fae355dac741c6a52fbafe5dc1f8a9a4210cdcc46ffab0265b1fd1819763fb197a3361287aa941f3d1d5177f4ac5dfcceb9c1abeab9976be16e517577c8187c230550a25be47b76e0126e5116d4efcf7a56c2be740601d1333f26b3ddbadf71b21c4fa11bb01544096c375d84a17aea638a6db69a338455d2b6fe5b5b7d3caec7b30cdb2952f2be9933a43a4987979824d281120cf11740779efae751d295d1540b3ffb62955fc10170763b13a1b2bdbfd863e138de5d24b9ff4aef6ab0af15f95e7aa6f6ec31c64901069413653cb56d692e69d26e9fe5bb050003010001000000")
      .formParam("secret", "121212")
      .check(bodyString.saveAs("LoginResponse"))
    )
      .exec(session => {
        println("LoginResponse:")
        println(session("LoginResponse").as[String])
        session
      })

  setUp(loginChallenge.inject(atOnceUsers(1)))
}

And I see this in a log:

POST /e2e_sim HTTP/1.1
accept: */*
origin: https://vm00006525.nl.eu.acme.com:9100
host: vm00006525.nl.eu.acme.com:9100
content-type: application/x-www-form-urlencoded
content-length: 615, content=null}
14:24:07.496 [gatling-http-1-2] DEBUG io.netty.handler.ssl.SslHandler - [id: 0x7d6f9fe8, L:/10.29.134.147:62478 - R:vm00006525.nl.eu.acme.com/10.240.78.133:9100] HANDSHAKEN: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Pay attention to the content=null part, that looks wrong. After that, Gatling tries many times to send the request until it times out like this:

Request:
Login: KO i.g.h.c.i.RequestTimeoutException: Request timeout to vm00006525.nl.eu.acme.com/10.240.78.133:9100 after 60000 ms
2

Doing this with Gatling version 3.x.x.

The actual version number matters. Please make sure you’re running latest version (3.2.0).

Pay attention to the content=null part, that looks wrong.

No, it’s correct.You’ve truncated the first line that would show you’re sending a FullHttpRequest that already contains the body bytes, and not a simple HttpRequest where body bytes would be written on the Netty pipeline as a distinct object (eg multipart or file upload).

As I said earlier, provide a sample we can run on our side so we can reproduce and investigate.
Without such sample, we can’t do much more than playing riddles.

3

At the very least, please provide the full TRACE logs, possibly privately.