Setting for "follow / don't follow redirects" on a per request basis.
First of all. Thank you for providing this great tool. I'm currently looking at alternatives and really have the feeling that a lot is being done right here.
To my question: Is it possible to set the follow redirects behaviour in general or on a per request basis? We actually need this because we want to extract a value from a response header that is only available without the redirect.
Hey @jkblume
Glad that you like Bruno!
Is it possible to set the follow redirects behaviour in general ?
Currently it's not supported. We will support it soon. By default all requests follow up to 5 redirects.
Is it possible to set the follow redirects behaviour on a per request basis?
Currently it's not supported. But I'd love to understand the requirement more and see if we can support it. Bruno uses axios under the hood. And we can expose an api that would allow you to set the maxRedirects for a request to 0.
I am thinking something like this which can be written in the pre request script section
req.setMaxRedirects(0);
Do you think an api like this would solve your use case?
Yeah, this would be totally fine!
Some insights to the use case: I am building a collection, that needs to get some value (a code challenge value, in an oauth2 workflow). This header value is present on an Response with status code 302, but gets lost if you follow the redirect. Hope this helps to understand, why this setting is important for us :)
Thanks for the fast response 👍
Hey @jkblume
This is now available in v0.15.0
Please download the latest version.
Here is how you can disable max redirects at the request level.
I also wrote some tests on our testbench to verify this. In case you are interested, the testbench repo (with test server and a collection) is at https://github.com/usebruno/bruno-testbench
Thanks, I will try this out the next days!
Hi, sorry for commenting on a closed issue, but this solution is not enough for me.
I need to make some sequential requests to get a token, and one of these requests requires not to follow redirects and extract some information from header.location, and use this information in the next request. So I need to use Post Response script and save it in an environment variable.
If I use req.setMaxRedirects(0); in 'Pre Request' I can't access the res object because the request throws an error and doesn't return the object.
I cloned the repo, started to play with your code, and created a new preference toggle called 'Follow Redirects' which defaults to true. I have added setMaxRedirects(0) if the flag is false and I also added a condition in Axios's response interceptor, so that if a 301 or 302 Http Status response is received, I still return the response object (instead of rejecting the Promise).
This has enabled me to successfully grab the headers from a 302 response, when I run the requests manually, one after another.
I just need to find out how to apply this when I run a collection, because it's failing right now.
I think we could also add this to the collection settings so there is no need to dig in the documentation
图形界面设置是否重定向或者重定向次数,比手动添加 Pre Request Script 的方式更直观友好
I hear @AndreiaSofia . Ran into a similar issue, I suspect with the same authentication format - with CAS: https://codenoble.com/blog/cas-authentication-explained/
In the flow, the last step is a page with the cookie set on it, and then a redirect. It works fine on the browser because the browser keeps the cookie - but not in a direct API flow like when using Bruno.
There should be an option not to follow redirect and that the request will not error because of that
I just tried this on Bruno v1.26.2 and it worked without an error message. I could see the response with the redirect header.
A setting for this at the request would be nice, so that it could be easily found when needed.
So when I was using bruno to call a URL, I would get 405 from the URL. I exported it to CURL and ran it and got a 301 instead, which is when I realized that it wasn't following the redirect from URL to www.URL. Strange though that I got a 405 instead of the 301 that the exported curl gave me! Anyway, thought I'd drop this by as a point in favor here.