Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bring back lost 'follow' (redirects) request option #324

Merged
merged 4 commits into from Oct 24, 2017

Conversation

Projects
None yet
3 participants
@robingustafsson
Copy link
Member

commented Sep 25, 2017

I needed this functionality and then realized we seem to have lost it in the Otto -> Goja migration, as it was previously implemented, see #232.

Usage:

http.get("https://httpbin.org/redirect/1", {follow: false});
check(res, {
    "has status 302": (r) => r.status === 302,
    "has non-redirected URL": (r) => r.url === "https://httpbin.org/redirect/1"
})

@robingustafsson robingustafsson requested a review from liclac Sep 25, 2017

@liclac

This comment has been minimized.

Copy link
Collaborator

commented Oct 4, 2017

I think this option would do better as an override for the number of redirects.

@robingustafsson

This comment has been minimized.

Copy link
Member Author

commented Oct 5, 2017

@liclac Ok, sounds reasonable. And a maxRedirects: 0 would return last response (return http.ErrUseLastResponse from CheckRedirect in Go) rather than throwing the "max redirects..." error? Because that's a real use case, that you want to interfere with redirects.

@liclac

This comment has been minimized.

Copy link
Collaborator

commented Oct 5, 2017

What if follow could be either a number or a bool, and if it's false that happens? But at that point, it may be better to just have two different options...

@luxifer

This comment has been minimized.

Copy link

commented Oct 12, 2017

Hi guys, this is a serious BC break and I really need k6 to not fail when there is a redirect...

@luxifer

This comment has been minimized.

Copy link

commented Oct 12, 2017

With maxRedirects: 0 in the options, the current respons status is 0, instead of the real http status code (should be 302 in my case).

@robingustafsson

This comment has been minimized.

Copy link
Member Author

commented Oct 13, 2017

@luxifer Do you mean removing follow: true|false would be a BC break, or are you saying that changing the behavior of maxRedirects: 0 is the BC break? In the latter case would you rather have the current behavior of an error being logged and status being 0, than having the first redirected response with 3xx status returned?

I'm thinking the best way forward might be to keep the maxRedirects behavior for now (keep it as a separate discussion whether to break that compatibility), and just reintroducing the follow: true|false as it's implemented in this PR right now. I'm also fine with implementing the follow: true|false|number version, although I'm a bit hesitant to having follow doubling as a per-request override for the global maxRedirects option under a different name.

@liclac Thoughts?

@luxifer

This comment has been minimized.

Copy link

commented Oct 13, 2017

That's exactly what I meant. The current behavior pour throwing an error when mawRedirects is 0 and the actual response code is 3xx is not good. I would like the follow option on http requests to be reintroduced thot that I can check that I am currently redirected.

Thanks!

@robingustafsson

This comment has been minimized.

Copy link
Member Author

commented Oct 18, 2017

Ping @liclac

@liclac

This comment has been minimized.

Copy link
Collaborator

commented Oct 18, 2017

What about this:

  • Default to following 10 redirects
  • Use { redirects: 5 }, etc. to change this
  • Return the last response, but log a warning if the redirects option isn't specified to prevent confusion ("why is my check failing??")
@robingustafsson

This comment has been minimized.

Copy link
Member Author

commented Oct 19, 2017

@liclac Ok, that sounds like a good idea to me. I'll change the implementation.

@robingustafsson

This comment has been minimized.

Copy link
Member Author

commented Oct 20, 2017

@liclac Now updated.

@@ -131,6 +132,7 @@ func (*HTTP) request(ctx context.Context, rt *goja.Runtime, state *common.State,
req.Header.Set("User-Agent", userAgent.String)
}

var redirects int64 = -1

This comment has been minimized.

Copy link
@liclac

liclac Oct 20, 2017

Collaborator

Put this below tags and make it redirects := -1. len() returns an int, not an int64, so there's no point in using an int64 here; cast the null.Int's int64 to an int further down instead.

if len(via) >= max {
return errors.Errorf("stopped after %d redirects", max)
max := state.Options.MaxRedirects.Int64
if redirects > -1 {

This comment has been minimized.

Copy link
@liclac

liclac Oct 20, 2017

Collaborator

Can we make this >= 0 instead?

max = redirects
}
if len(via) > int(max) {
if redirects == -1 {

This comment has been minimized.

Copy link
@liclac

liclac Oct 20, 2017

Collaborator

For consistency with the above, if redirects < 0.

state.Logger.WithFields(log.Fields{
"error": fmt.Sprintf("stopped after %d redirects (controlled via option \"maxRedirects\")", max),
"url": via[0].URL.String(),
}).Warn("Redirect Limit")

This comment has been minimized.

Copy link
@liclac

liclac Oct 20, 2017

Collaborator

Make this something like "Possible redirect loop, {{ via[0].Status }} response returned; pass { redirects: n } to silence this". It doesn't matter if this is long, it should only be printed very rarely to make sure the user isn't accidentally doing the wrong thing.

@robingustafsson robingustafsson force-pushed the feature/follow-redirects branch from 75c1b36 to 6809299 Oct 23, 2017

@robingustafsson robingustafsson force-pushed the feature/follow-redirects branch from 6809299 to 0d6d24f Oct 23, 2017

@robingustafsson

This comment has been minimized.

Copy link
Member Author

commented Oct 23, 2017

@liclac Requested changes have been made.

@liclac

liclac approved these changes Oct 24, 2017

@liclac liclac merged commit e107dbe into master Oct 24, 2017

1 check passed

ci/circleci Your tests passed on CircleCI!
Details

@liclac liclac deleted the feature/follow-redirects branch Oct 24, 2017

@liclac liclac restored the feature/follow-redirects branch Nov 23, 2017

@na-- na-- deleted the feature/follow-redirects branch Mar 12, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.