Feature request: Disable follow redirect for single request

Gatling (Open-Source)
1

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.

2

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?

3

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.

4

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.

5

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.)

6

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.

7

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.

8

Makes sense.

Will do, thanks for sharing your science :slight_smile:

9

You’re welcome.
Glad to help :slight_smile: