Gatling Recorder ignores Cookie and Set-Cookie header

Gatling (Open-Source)
1

Hello,

After an afternoon of digging, I have figured out how I could manually write a Gatling script which makes use of cookies. However the Recording feature seems to completely ignore cookies, which if intended I can’t find clearly documented.

As an example, I set up a super-simple node app demonstrating the use of both Cookie and Set-Cookie.

  1. I would expect Gatling not to ignore the “Cookie: xyz” header the browser-generated request is sent with.
  2. Or, I would expect Gatling to have specialized cookie processing; and to act like a browser itself, so that a “Set-Cookie: xyz” that works on major browsers would result in that cookie being used on subsequent requests.

Then I fired up my newly installed Gatling 2.3.0 (on Ubuntu), and tried recording and replaying my app. This has the same effect that using Gatling on my big web app had: all requests are (correctly) rejected by the server for lack of expected cookies.

Since I have a big complicated web app, I’d rather not code all simulations by hand, nor sort through the myriad requests, inserting the right cookies on the requests that need them. That script would probably be subject to frequent breakage.

What can be done here? Shouldn’t Gatling [Recorder] not ignore cookies?

Thanks,
Sam Berney

2

Case 1, Cookie: ‘IdentityCookie=admin’ ignored

Gatling transparently deals with cookies set by the server (hence originating from a Set-Cookie header).As such, the Recorder doesn’t record “Cookie” headers in the generated simulation.

What you do here is manually setting a cookie in the browser with Javascript.
We just can’t detect this and that’s something you must re-implement (see HTTP helpers doc).

Case 2, Set-Cookie: IdentityCookie=admin; Path=/ ignored

Sorry, works just fine for me.

class CookieSimulation extends Simulation {

val httpProtocol = http
.baseURL(“http://localhost:1139”)
.acceptHeader(“text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8”)
.acceptEncodingHeader(“gzip, deflate”)
.acceptLanguageHeader(“fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3”)
.userAgentHeader(“Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:56.0) Gecko/20100101 Firefox/56.0”)

val scn = scenario(“CookieSimulation”)
.exec(http(“request_0”).get("/login"))
.exec(http(“request_1”).get("/successful-authentication"))
.exec(http(“request_2”).get("/"))
.exec(http(“request_3”).get("/admin-page"))

setUp(scn.inject(atOnceUsers(1))).protocols(httpProtocol)
}

3

Thanks Stéphane, for your helpful response,

I’m not sure why Case 2 wasn’t working for me yesterday, but I tried again and it is working.

It might be nice to have a toggle flag to behave like Case 1: Unless the server is issuing one-use nonces and/or keeping state, everything would just work, right? Wouldn’t it be faster to get things set up? It seems like something which could be trivial to implement, which could help in situations where perhaps cookies are manipulated in the browser.

Or otherwise possibly to state that cookies are treated specially [by everything] and that Cookie headers are not saved [by the Recorder], like most everything else is. Most of the materials or discussions I could find either talked about how to write scripts which set cookies, or how to scan responses for data, and add it as a header or as a cookie – I guess, not about what the Recorder is doing.

I am actually still trying to get my main application to work, and I’m just wistfully wishing for an exact request replay.

Thanks,
Sam Berney