Extracting cookie/header value

Hey me again. I need to maintain a session cookie across a user's
requests. I think the easiest way would be to extract the SET-COOKIE
header from my first request, save that to the session, and then
inject that into each subsequent request. Unfortunately I'm having
trouble with the first step. Here is what I'm trying:

val resourceGet = chain.exec(
                        http("getResources")
                        .get("/resources/1")
                        .headers(headers_1)

.check(header("SET-COOKIE").exists).find.saveAs("sessionToken")
                )

I adapted this from the "Saving values" section here:

https://github.com/excilys/gatling/wiki/Checks-Reference

This doesn't work and i've tried other combinations like removing the
'find' but all throw errors something like:

/local/dev/gatling/user-files/simulations/20120131002614_scenario@default_scala.scala:258:
error: value find is not a member of
com.excilys.ebi.gatling.http.action.HttpRequestActionBuilder

.check(header("SET-COOKIE").exists).find.saveAs("sessionToken")

So my first question would be how can I extract a header and save it
to a session variable?

Also from looking at the code it seems like headers expect 1 value for
a specific header name. For SET-COOKIE headers in particular it is
common to have multiple with the same name. Is there any way in
Gatling to extract the one I want? I would need to find the
SET-COOKIE header with a value like
"JSESSIONID=E2F98A8757AC931AEE67AAE5E3B769DC; Path=/" and then extract
the token from that.

Any tips?
Chris

Hi Chris,

Gatling already does that for you and automatically stores cookies in the session and pass them to the next requests.

Stephane

2012/2/2 Chris Carrier <ctcarrier@gmail.com>

Hi Chris!

Cookies are transferred from one request to another automatically! :slight_smile:

You do not have to worry about them. If one is received, it will be sent in the subsequent requests :slight_smile:

Cheers,
Romain

Ha ha! Same time :slight_smile:

hi,

i have a problem with this, when gatling automatically adds the cookie it looks like:
Cookie: JSESSIONID=
JZbAsTiFobLcVZHjjZO04a+o.6e350609-5758-3190-aec9-794334ced8d1;$Path="/Admin"

instead of
Cookie: JSESSIONID=JZbAsTiFobLcVZHjjZO04a+o.6e350609-5758-3190-aec9-794334ced8d1;Path=/Admin

Hi,

What does your scenario look like?
Could you for example provide a gist?

Steph

2012/2/3 mediamana <mediamana@free.fr>

i’ve resolved my problem it was a rule in mod_security that doesn’t like $Path="/Admin" even if it is a valid part for a cookie

sorry for the inconvenience

No problem :slight_smile:

I'm not getting my cookie set automagically so maybe you can help me
understand how the cookie handling works. Will the cookie be applied
to every request after it is set? Will it apply across different
chains as long as they're in the same scenario? Here's what i'm
trying to do

val chain1 = //some http call that will return multiple Set-Cookie headers
val chain2 = //a bunch of static content requests that don't require
the cookie is set
val chain3 = //another http cal that needs the cookie from chain1

val scn = scenario("...").insertChain(chain1).insertChain(chain2).insertChain(chain3)

But on the chain3 request it doesn't seem like the cookie is being set
in the request. The cookie should be set for all requests for a
particular user right? Is there any way for me to debug what gatling
is actually sending? Can I somehow config Gatling to print the full
request in the simulation.log? Or can I println session attributes
but so far I haven't been able to find what attribute the cookie is
set in.

I imagine I'm doing something wrong but I'm not sure the best way to
debug what Gatling thinks should be sent for each request.

Chris

OK I may have found the issue. I used a debug chain like this to
print out the Session attributes:

val debugChain = chain.exec( (s: Session) => println( s.data) )

When I do this right after chain1 (that sets the JSESSIONID cookie) I see:

gatling.http.cookies -> Map(JSESSIONID -> Cookie: domain=null,
name=JSESSIONID, value=9862CA687E7D7F8885EFC4416B29CCDB, path=/,
maxAge=-1, secure=false...

But after chain2 I print it again and see:

gatling.http.cookies -> Map(JSESSIONID -> Cookie:
domain=.facebook.com, name=JSESSIONID, value=deleted, path=/,
maxAge=-1, secure=false

Is the 'value=deleted' something that Gatling is doing? Is there any
way to tell it to retain the cookies over the life of a user's
session? I figure as a workaround I can manually extract the
'gatling.http.cookies' from the session and grab the cookie value and
then use it wherever I want. Gonna give that a shot right now.

Chris

Hi Chris,

Actually, Cookies are really passed through the session. The thing is that we map them by their name.

In your case, it seems that both cookies are named jsessionid, which leads to an overriding of the first one by the second.

Maybe we should map them by both name and domain, so that cookies will never be overridden by mistake.

Thanks for pointing it out Chris!

Cheers,
BluePyth

I opened the following issue and will start fixing it today :
https://github.com/excilys/gatling/issues/396

2012/2/4 Romain Sertelon <bluepyth@gmail.com>

Great this will be a big help for us.

Thanks!
Chris

I think I’ll have something ready for friday (sadly not much time until then) and I’ll upload a 1.1 snapshot somewhere then.
Thanks for your patience,

Stéphane

2012/2/7 Chris Carrier <ctcarrier@gmail.com>

Hi Chris,

I’ve uploaded a snapshot of the next 1.1.0 release, with a fix for cookie handling.

I’m quite in a rush and barely had the time to test the fix…
Could you please let me know if it indeed solves your problem?

Warning : Check DSL change :

  • eq becomes is
  • neq becomes not
    Don’t forget to modify your existing scenarios.

Sincerely,

Steph

2012/2/7 Stéphane Landelle <slandelle@excilys.com>

I'll do a quick code review and test it out and let you know if I see anything.

Thanks for the quick turn around!
Chris

So far this fix seems to be working great. Thanks again!

Chris

Great news!

Thanks for your feed back and have fun,

Steph

2012/2/9 Chris Carrier <ctcarrier@gmail.com>