Recorded scenario doesn't play back successfully

Snap. Hmmm, that makes it more difficult to diagnose then.

Yes, https everywhere.

You have the right sequence. Basically, upon login, the response sets header elements in the cookie to match the domain. What I am experiencing is that the previously set cookie headers are no longer then when making subsequent request to the server, those causing a 403.

Also, machine2.subdomain.ourdomain.org/regis/home, which still falls under *.ourdomain.org.

Let me know if you need additional info

Hi,

The fact there are two subdomains is probably the source of the problem.
I just did a fix, the build takes a while but should soon be over : https://gatling.ci.cloudbees.com/job/gatling/314/

May you be able to test that my fix is working for you ?
You can grab the last snapshot from here : http://repository-gatling.forge.cloudbees.com/snapshot/com/excilys/ebi/gatling/highcharts/gatling-charts-highcharts/2.0.0-SNAPSHOT/

Thanks a lot !
Nicolas

Hi Nicolas -
I gave this a spin and it is still not working unfortunately. The cookie headers are still lost on subsequent requests after successful login

Hi,
Thanks for the testing … but I’m slowly running out of ideas.

Wouldn’t it be possible to send me the log output when everything is uncommented in the logback.xml file?
By doing just these two requests for 1 user, there probably wouldn’t be so much data to anonymise …

Nicolas - can you send me your email? I’ll send it directly to you once i get that.

Cheers

shoot me an email @ groovybayo@gmail.com

So, here is the problem. You request looks like this one : 
POST https://b.a.foo.com:443/123/login/home/login/process
Set-Cookie: cookie1=AQIC5wM2LY4Sfcx; Path=/; Domain=.foo.com; Secure

And this is what we can find the RFC 2109 (http://www.ietf.org/rfc/rfc2109.txt) :

   * The request-host is a FQDN (not IP address) and has the form HD,
     where D is the value of the Domain attribute, and H is a string
     that contains one or more dots.

   Examples:

   * A Set-Cookie from request-host y.x.foo.com for Domain=.foo.com
     would be rejected, because H is y.x and contains a dot.

This is why, currently, Gatling is ignoring the value of cookie1.

Now, it seems that RFC 6265 is now the reference … and I’m not sure if the previous rule is still valid or not, cf : http://tools.ietf.org/html/rfc6265#section-4.1.2.3
I’ll try to read more tomorrow, these RFCs are a headache.

cheers
Nicolas

Ha - I see. That is a lot to digest and a whole lot of reading.

Like I had mentioned previously, this also works in Jmeter, so it seems RFC 6265 is the new/replacement standard.

Thanks

[Off topic]

You can prettify RFCs thanks to this webapp https://pretty-rfc.herokuapp.com/

Unfortunately, it does not work for every RFC (6265 won’t work:/), but still, it makes reading those prettified a lot better :wink: You might appreciate it someday!

[/Off topic]

Can I ask you to try the last snapshot ?

I started updating the domain matching of cookies to the RFC 6525 … it made me realise how incomplete our current implementation is, I’ll have to work on that sometime soon.

Thank you !
Nicolas

Cool. I am away this weekend. I’ll try it once I get back and keep you posted.

Thanks

Hi Nicolas - I tried the latest snapshot and unfortunately, it’s still not working. Same issue.

Cheers

Can I ask you to send me again a log file? The problem may be slightly different…

Thank so much.

Hi Nicolas - I just sent it

Just to close the loop on this for anyone else running into a similar issue.

A fix has been put in by Nicolas

Refer to

https://github.com/excilys/gatling/pull/926

Commit sha

Cheers