cookies are not getting saved, if the Set-Cookie has Expires parameter

I am new to Gatling, I am using gatling-charts-highcharts-2.0.0-M3a, i can see that all the requests have cookies that doesn’t have ‘Expires’ in the Set-Cookie, but cookies are missing if Set-Cookie has ‘Expires’. Please help

CookieJar has been fully refactored in 2M4. Could you give the snapshot a try, please?

I dont see a link to 2M4, can you give me the link.

Here you go :

https://oss.sonatype.org/content/repositories/snapshots/io/gatling/highcharts/gatling-charts-highcharts/2.0.0-SNAPSHOT/

I’m also getting issues with cookies (2.0.0-SNAPSHOT). It’s a challenging scenario, so I don’t know how much of an example I can give. Browsing the website, I’m able to successfully go through the workflow, however after saving out the recording, Gatling enters into an infinite redirect loop - presumably because a cookie is failing to be set, or perhaps sent. Here’s the basic flow:

  1. User logs into the auth app
  2. User is redirected to CAS, which authenticates
  3. User is redirected to the application, which thinks the user has an anonymous role.
  4. User is redirected back to CAS, which authenticates
  5. Repeat 3-4.

We haven’t been able to reproduce this behavior anywhere else besides in Gatling and the browser and Gatling both are making the same requests up until the point of the redirect loop. We’ve tried putting Charles Proxy in front of Gatling, but it isn’t picking up any of the activity from Gatling, so unfortunately we can’t see the raw headers being sent around. I’m currently using the extraInfoExtractor to just log out request.getCookies, but I fear this may be too late in the process.

Thoughts? And as a secondary, any thoughts on why the proxy would work for everything except Gatling (we’ve configured the http.proxy settings in gatling.conf)

Could you provide a Charles export of your challenge sequence from your browser, please?

Regarding recording Gatling through Charles, we’ve removed the ability to set up a proxy in gatling.conf: too many way of doing the same thing.
Just use the HttpProtocol.

Huzzah. We got proxying to work - just required setting proxy via the httpProtocol instead of the config. That brought some light to our issue, which turns out isn’t a cookie issue afterall.

It would appear that Gatling is doing some funky url appending while making requests, and it was exposed by Tomcat giving a redirect on a relative URL. I’d love to see if you’re able to reproduce this URL construction: http://cl.ly/image/1Q1u03211Q2k

What the hell???

What does the previous Location header look like, please?

This is the first request in the entire simulation: http://cl.ly/image/2T122T14453n

It looks like the protocol & host within the path, so when the request is made, it just appends all of it together.

Would it be possible to share your protocol and this first request definition, please?
I can’t reproduce.

OK, it looks like SSL proxy support is broken.
Investigating.

Yep: with a SSL proxy, the client should send a relative URI once connected.
But AsyncHttpClient sends an absolute one!

I think AHC default behavior is wrong.

In gatling.conf, could you switch useRelativeURIsWithSSLProxies to true, please?

Fixed from Gatling side: https://github.com/excilys/gatling/issues/1728

@Rob: this was probably a different issue from your original one with cookies. This one was really about setting a SSL proxy.

This is good! Note, however, we were having redirect issues prior to the proxy (which we only enabled to figure out what was going on). I’ll post more information as we find things.

Here’s the httpProtocol and first request:

class Example extends Simulation {

val httpConf = HttpProtocolBuilder.default
.baseURL(“https://vagrant.moolb.com”)
.acceptHeader("/")
.acceptEncodingHeader(“gzip,deflate,sdch”)
.acceptLanguageHeader(“en-US,en;q=0.8”)
.connection(“keep-alive”)
.userAgentHeader(“Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.110 Safari/537.36”)
.extraInfoExtractor(infoExtractor)
.proxy(Proxy(“127.0.0.1”, 8888).httpsPort(8888))

val firstReq = exec(
http(“SignupPledge”)
.get("/signup/pledge")
)

}

CONFIDENTIAL COMMUNICATION:

This email may contain confidential or legally privileged material, and is for the sole use of the intended recipient. Use or distribution by an unintended recipient is prohibited, and may be a violation of law. If you believe that you received this email in error, please do not read, forward, print or copy this email or any attachments. Please delete the email and all attachments, and inform the sender that you have deleted the email and all attachments. Thank you.

FWIW, changing that setting fixed the request header, but the URL redirects are still happening.

CONFIDENTIAL COMMUNICATION:

This email may contain confidential or legally privileged material, and is for the sole use of the intended recipient. Use or distribution by an unintended recipient is prohibited, and may be a violation of law. If you believe that you received this email in error, please do not read, forward, print or copy this email or any attachments. Please delete the email and all attachments, and inform the sender that you have deleted the email and all attachments. Thank you.

Yep, as I expected, different issues.

I was asking for the setp up and request when I thought it was a single one.

Now, I’m back to asking you a Charles dump of your browser sequence…

Thanks for your patience.

Stephané,

Dumps can be found at the bottom. Some explanation, as well as a theory:

Our topology uses multiple tomcat apps for various things (authentication, shopping, etc). Each has its own JSESSIONID attached to a certain path (e.g. app1: “/”, app2: “/app/auth”, app3: “/app/consumer”). In the browser, the request passes along each JSESSIONID, but in Gatling, only one is set - presumably because it’s setting based on the name of the cookie only. Since the app we’re trying to go to isn’t seeing its expected JSESSIONID, it redirects to CAS to authenticate, then loops around because JSESSIONID is already set by a different application. Hope that makes sense.

Trace files: http://cl.ly/0i1m0e443G2Y

CONFIDENTIAL COMMUNICATION:

This email may contain confidential or legally privileged material, and is for the sole use of the intended recipient. Use or distribution by an unintended recipient is prohibited, and may be a violation of law. If you believe that you received this email in error, please do not read, forward, print or copy this email or any attachments. Please delete the email and all attachments, and inform the sender that you have deleted the email and all attachments. Thank you.

Thanks! Will investigate later this week-end.

After 1h digging in those logs, finally found where the problem lies: https://github.com/excilys/gatling/blob/master/gatling-http/src/main/scala/io/gatling/http/cookie/CookieJar.scala#L134

Nervous breakdown…