Feature request: Disable follow redirect for single request

[Rob Zienert]

Hi there,

This isn't supported to my knowledge, but it would be nice if I could disable redirects for a single request only, as opposed to an entire httpProtocol. If it isn't possible, I'd love to know why for curiosity's sake.

Thanks!

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.

[Stéphane Landelle]

Hi Rob,

Feasible, of course.

But could you elaborate why you need this? I would sadden me to end up duplicate every possible HttpProtocol option because, he, why not?

--
You received this message because you are subscribed to the Google Groups "Gatling User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gatling+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rob Zienert]

Well, I don't want to make you sad. This was purely for debugging purposes - I think we can live without if it's a design issue.

[Stéphane Landelle]

Nothing compared to your cookie issues...

I'll just keep this somewhere in my head, in case someone else ask for it and it makes sense.

[Floris Kraak]

Actually, we do have several different situations in our tests where we do exactly that:

- logout stub in test redirects to prod homepage. - No, thanks. And we only want to know the redirect responstime anyway ..

- The redirect sends the user to a different system, and we want to know responsetimes from both, so we split them into two requests, and measure them seperately.

- the login happens on a stub system that isn't realistic at all, and we're only interested in the responstime of what that page redirects *to*. So, again, we split the measurements.

The best way to achieve either of these is to temporarily disable redirects and turn them back on afterwards.

And it's not rare, either - the login thing happens for basically every testscript that has something to do with the customer-only side of the internet portal. Which is at least 60-70% of our testwork. And as you may be aware, it's not exactly a small group of testers ..

*) (Though to be fair we also filter url's that navigate away from the test environment, so we have defense in depth there.)

--

REALITY.SYS corrupted. Reboot Universe? (Y/N/Q)

[Stéphane Landelle]

Even with followRedirect enabled, Gatling logs all the requests of the redirect chain individually.

Assuming your initial request was named Foo, you'd get Foo, Foo Redirect 1, Foo Redirect 2, etc. 

[Floris Kraak]

But what if you want to call "Foo" and "Foo 1" something else?

Something like "Login" and "Portal Start Page", say.

And moreover, what you want to call a *different* invocation of that same start page "Portal Start Page" as well, so that we can aggregrate all hits on that page into a single measurement?

(User returns to start page while logged in.. so not coming in from login page, but through some hyperlink or perhaps even through pressing "F5").

And how about correlations? The login redirect will need different checks than the portal start page. In fact: Depending on form parameters, that login can redirect you to a completely different URI, which needs yet another, completely different set of checks.

So err, no. It goes a lot deeper than merely getting a seperate measurement: In the transaction library it's really it's own seperate entity.

[Stéphane Landelle]

Makes sense.

Will do, thanks for sharing your science :)

[Floris Kraak]

You're welcome.
Glad to help :)