How to handle response body upon getting different status (200/302)

Gatling (Open-Source)
1

Gatling version:
Gatling flavor: java kotlin scala javascript typescript
Gatling build tool: maven gradle [x ] sbt bundle npm

I made sure I’ve update my Gatling version to the latest release
I read the guidelines and how to ask a question topics.
I provided a SSCCE (or at least, all information to help the community understand my topic)
I copied output I observe, and explain what I think should be.

Hi I am handling a login a bit like this:
exec(http(“login”)
.post(“#{loginUrl}”)
.queryParam(“session_code”, “#{session_code}”)
.formParam(“username”, “#{username}”)
.formParam(“password”, “#{password}”)

But the response status can be either 200 or 302.

In case of .check(status.is(200)), I can just continue

However if the case of .check(status.is(302)), I need to fetch additional parameters out of the response body like:
.check(regex(“url="(.+?)(?=[?])”).saveAs(“newUrl”))
.check(regex(“session_code=(.+?)(?=[" &])”).saveAs(“newsession_code”))
and the make addition calls before I can continue

So my question is there a smart way of handling these two ways of handling the response from the status check ?

Best regards
Casper S.

2

First, it tends to be a bad practice to try to read the body of a redirect response. JavaScript executed in browsers don’t have access to it and browsers handle redirects transparently. Code only has access to the final landing page, which in Gatling translates to using currentLocation checks.

Then, if you absolutely want to parse the redirect response body, you must:

  1. make Gatling stop following redirects transparently: Gatling HTTP protocol reference - protocol configuration
  2. use a conditional check to parse the response body depending on the status: Gatling checks scripting reference
1 Like
3

Thank for the fast response, Ill check if I can rewrite it, but there is a lot of ping pong in the authentication I have to handle

4

What is your real world HTTP client? Web browsers? If so, you shouldn’t have to inspect the redirect response bodies.

5

yeah its just http web browser that does login towards authentication server. I just tried to mimic exactly what a web browser did to ensure correct login. But now ill try without disabling and explicit handling of redirects :sunglasses:

6

Thx for the support @slandelle I have followed your advice and obtained a more clean flow, which handles the different status :+1: