Recorded scenario doesn't play back successfully

Hi -
I have just recorded a scenario with the recorder, and before I start making modifications to it (via injecting feeders, and what not), I run the simulation and most of the requests get KO.

Scenario steps:

  1. Attempt to access secure URL
  2. Redirect to login page
  3. User authenticates
  4. User is routed back to resource requested in 1)
  5. User logs out

When I replay the scenario, all requests in 4) fail with warnings in the logs indicative of a 403 response status (like below) and others pass. Step 3, succeeds, so I am a bit puzzled.

08:14:21.171 [WARN ] c.e.e.g.h.a.GatlingAsyncHandlerActor - Request ‘request_10’ failed : Check ‘in’ failed, found 403 but expected Range(200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210)
08:14:21.220 [WARN ] c.e.e.g.h.a.GatlingAsyncHandlerActor - Request ‘request_11’ failed : Check ‘in’ failed, found 403 but expected Range(200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210)

How can I go about debugging this? Any ideas?


What version of Gatling are you using ?

The latest and greatest! 1.4.2

There was an issue with cookies not set that could have been a cause for your problem, but it was only present in 2.0-SNAPSHOT.

If you want to debug your simulation, your best shot is changing the log level in logback.xml (you can find it in the conf/ folder) : uncomment line 16 (if you want to get debug info from all your requests) or 18 (if you want to get info only from failed requests).
You’ll be able to see exactly what was sent and what you got back from your server.



Thanks Pierre
I turned on logging for all requests, and what is happening is that the cookie for subsequent calls after the user authenticates. I have no clue why that will be happening. I am using 1.4.2, which you mention does not have this bug.

See a snippet of the response after authentication, and a request immediately after (which is missing the cookies that got set earlier)

13:47:53.419 [INFO ] c.e.e.g.h.a.HttpRequestAction - Sending Request ‘request_4’: Scenario ‘Scenario Name’, UserId #1
13:47:53.785 [TRACE] c.e.e.g.h.a.GatlingAsyncHandlerActor -

request was:
POST https://host/login
X-Requested-With: XMLHttpRequest
Accept: text/html;type=ajax
Connection: keep-alive
Accept-Encoding: gzip,deflate,sdch
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Origin: https://
Accept-Language: en-US,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.52 Safari/537.17
Cookie: domain=, name=JSESSIONID1, value=0001HT3x_Nm8ZSVxZeiH48fOZ5O:168drei33, path=/, maxAge=-1, secure=false
Cookie: domain=somehost_YYY, value=NAwxdfySFs9ZYte0Dy6QOxbCFMFxjCCY5W2bUN0lgYq3rp2CmssZW1B3O6kZwvLMSIE/2+hWqLAj3oCmtfM=, path=/login/, maxAge=-1, secure=false
userSecurity.password: pass
fragments: body
user.username: user
cancelUrl: modal:/home/login/standalone?gotoUrl=

response was:
200 OK
Set-Cookie: iPlanetDirectoryPro=AQIC5wM2LY4SfcwzRgave3X5R5j3N2Fb1yqKzSGshLEu1IM.AAJTSQACMDIAAlMxAAIwMQ…;; Secure
Connection: Keep-Alive
Content-Language: en-US
Content-Length: 1048
Content-Type: text/html;charset=ISO-8859-1
Cache-Control: no-cache=“set-cookie, set-cookie2”
Expires: Thu, 01 Jan 2018 12:00:00 GMT
Date: Sat, 19 Jan 2013 18:47:53 GMT
Server: Tomcat
Vary: Accept-Encoding

13:47:56.808 [INFO ] c.e.e.g.h.a.HttpRequestAction - Sending Request ‘request_5’: Scenario ‘Scenario Name’, UserId #1
13:47:56.831 [TRACE] c.e.e.g.h.a.GatlingAsyncHandlerActor -

request was:
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Language: en-US,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.52 Safari/537.17

<<<< NO COOKIES HERE, WHY??? >>>>

As the bug is not present in 1.4.2 and considering that my knowledge of the HTTP protocol is not as good as Stephane’s, the reason of cookies not being sent currently eludes me.
I’d like to check if there’s anything in 1.4.2 that could break cookies handling that got fixed in 2.0.
Would you mind trying a 2.0 snapshot ?
There’s been a few changes in the DSL breaking compatibility with 1.4.x (the akka.util.duration import changed to scala.concurrent.duration and the Session API changed a bit) but it should be easily fixed.
I keep looking at where it could come from.



Thanks Pierre. I’ll take v2 for a test drive and keep you posted.

I uploaded a snapshot, here is the link :

Basically, if you don’t use Session functions (see here for more details about Session functions), your simulation should compile fine if you replace import akka.util.duration._ (line 7) by import scala.concurrent.duration._ .

Unfortunately, it’s the same result. No worky ;(

I am able to point to other hosts on our next work and those are set correctly. Maybe it’s something specific to this server I am trying to record against.

This is irritating…

Thanks for you help.

I don’t see any obvious problem … Would it be possible for you to share the Gatling script and the associated traces when logging all the requests ?

Could you also help me to make this clear ?

POST https://host/login


Set-Cookie: iPlanetDirectoryPro=AQIC5wM2LY4SfcwzRgave3X5R5j3N2Fb1yqKzSGshLEu1IM.AAJTSQACMDIAAlMxAAIwMQ…;; Secure

Did you rewrote the log with custom hosts ?
The cookie is assign to the domain, so, obviously, when doing a GET, there won’t be any cookie.


Nicolas - unfortunately, i can’t do that. I’ll try and come up with something I can share sometime soon.

Is there a way to preserve my filter settings in the recorder? Or where are those stored on the file system. I just tried 2.0-snapshot now, booted up the recorder, recorder a quick scenario and when i boot back to 1.4.x and boot up the recorder in that, all my filter settings are gone.

Yes i had to edit that since it contained actual host names and ip addresses on our co-operate network :wink:

They get really sensitive about stuff like that

Right, I understand. But, could you check my point about the cookie domain. Are there actually matching ?

Yes, i just checked, that matches.

The machine I am running the simulation on the same network ( as that of the authentication server

Set-Cookie: iPlanetDirectoryPro=AQIC5wM2LY4SfcwzRgave3X5R5j3N2Fb1yqKzSGshLEu1IM.AAJTSQACMDIAAlMxAAIwMQ…; Path=/;; Secure

BTW, I just spinned off a jmeter script against this problematic host and when i run, it all works. I am not getting a 403 after authentication, which further mystifies me

Well, this is the point I think.

I have been able to reproduce the issue.

“Failing example” in {

val cookie = parseCookie(“ALPHA=Value1;;”)

val cookieStore = CookieStore(new URI(“”), List(cookie))

cookieStore.get(new URI(“”)).length must beEqualTo(1)


I have started to work on a fix but the RFC is a bit complicated and I’ll go skiing early tomorrow morning. Is that OK if you get a fix on Monday ?



Wonderful! Monday is fine. You guys rock! It’s open source and I am quite impressed with the response time whenever I raise an issue or question.

Thanks for a great product.

Ping me when I can pull your fix and test.

Enjoy your ski

Would you like me to raise an issue or do you already have that covered?

Well, the example I was quoting is actually working… so, I’m still trying to understand the problem :-S

Can we go through the scenario again ?

1/ Request:
Response headers:
Status: 304
Set-Cookie: iPlanetDirectoryPro=AQIC5wM2LY4SfcwzRgave3X5R5j3N2Fb1yqKzSGshLEu1IM.AAJTSQACMDIAAlMxAAIwMQ…; Path=/;; Secure

2/ Request:

The “Cookie” header is empty.

Are we really on “https” everywhere ? Are the domains equivalent to what’s here ?