Http provider not returning "location" in response

I’m trying to use the http provider to make an authorization call to an API endpoint, which returns a 302 redirect, but if you change the method = “HEAD”, it should return a location response, which can be parsed to get the authorization token for further automation.
I found

which goes a step further to prevent the 302 redirect in a very similar use case as what I’m trying to do, but I just need the location returned. I have a PoC that works, I’m just wondering what the next steps would be to get it looked at as possibly a PR?

is where I have my updates… full disclosure, I’m learning Go as I go through this, so feel free to provide suggestions please. :slight_smile:

Hi @Beany :wave:

As you mentioned, the http provider currently follows redirects.

RFC7321 describes that a 302 should return a Location header and further describes what should happen in the case of other 3xx status codes.

The behaviour of the http client used within the provider would need to be modified on the basis of optional, practitioner-supplied configuration (e.g., no_follow_redirects, redirects_disabled), which could then be used to to determine whether to configure CheckRedirect on the http client, as has been suggested in the proposal linked from the Do not follow HTTP redirects issue that you mentioned.

Perhaps it’s worth commenting on the Do not follow HTTP redirects issue as the author of that issue recently asked about raising a PR, and discussion of that issue might provide one way to converge on a solution.

Hi @bendbennett
I’m kalsto on Github, but was trying to follow the contributing guidelines which suggested starting a conversation here… so … here I am. :slight_smile:

I used relvacode’s code to help me figure out what was needed for the location output I was looking for. I did this mostly because their enhancement was submitted almost a year ago and I hadn’t seen a PR for it yet, so I thought I’d take it to a slightly smaller piece of the puzzle that I felt I could figure out.

If you’d like, I can take a crack at updating relvacode’s Go, as it is slightly different from the current implementation of the http provider… I’m just really new at Go, so wasn’t sure if I could get it fully updated successfully.