# Http provider not returning "location" in response **URL:** \ **Category:** Plugin Development\ **Tags:** first-time-question\ **Created:** [September 20, 2023, 3:49pm UTC](https://discuss.hashicorp.com/t/http-provider-not-returning-location-in-response/58416 "2023-09-20T15:49:34Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Beany](https://avatars.discourse-cdn.com/v4/letter/b/e8c25b/32.png) [@Beany](https://discuss.hashicorp.com/u/Beany)\ **Post date:** [September 20, 2023, 3:49pm UTC](https://discuss.hashicorp.com/t/http-provider-not-returning-location-in-response/58416/1 "2023-09-20T15:49:34Z")
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 > > > \### Terraform CLI and Provider Versions > > \`\`\` > terraform version > Terraform v1.2.…6 > on darwin\_amd64 > \`\`\` > > \### Use Cases or Problem Statement > > The current version of this provider does not expose an option to \*\*not\*\* implictly follow HTTP redirects. > > It also does not document the behaviour of HTTP redirection, as highlighted in #60. > > In my use-case, I would like to use this module to call an HTTP server with some specific headers, such as Authorization. This server will then respond with a S3 URL which I would like to pass to another module that I do not want to propagate the origin server-specific request headers to. > > \### Proposal > > I propose that the provider adds the option \`no\_follow\_redirects\` to explicitly disable HTTP redirection and instead return the response of the first HTTP request made. > \`no\_follow\_redirects\` instead of \`follow\_redirects\` to make it obvious the default behaviour is to follow redirects, and setting the option to \`true\` disables this behaviour. > > I also propose that it adds an output named \`location\` that describes the absolute URL of the request that made the final response returned by the provider. > In the case that the server responds with a Location header, the \`location\` attribute is the absolute URL of the Location header value relative to the request that made the final HTTP request. > > \### Example 1 > > \`url\` is \`http://example.org\` which returns HTTP 200 OK > > \`status\_code\` is \`200\` > \`location\` is \`http://example.org\` > > \### Example 2 > > \`url\` is \`http://example.org\` which returns HTTP 302 Found and Location of \`/redirected\` > \`no\_follow\_redirects\` is \`false\` > > \<-- provider makes another request --\> > > \`status\_code\` is \`200\` > \`location\` is \`http://example.org/redirected\` > > \### Example 3 > > \`url\` is \`http://example.org\` which returns HTTP 302 Found and Location of \`/redirected\` > \`no\_follow\_redirects\` is \`true\` > > \`status\_code\` is \`302\` > \`location\` is \`http://example.org/redirected\` > > > > \### How much impact is this issue causing? > > Medium > > \### Additional Information > > I have written an implementation of this proposal at https://github.com/relvacode/terraform-provider-http/tree/feature/explicit-follow-redirects > > \### Code of Conduct > > \- \[X\] I agree to follow this project's Code of Conduct 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? > **[GitHub - kalsto/terraform-provider-http: Utility provider for interacting...](https://github.com/kalsto/terraform-provider-http)** > > Utility provider for interacting with generic HTTP servers as part of a Terraform configuration. - GitHub - kalsto/terraform-provider-http: Utility provider for interacting with generic HTTP server... is where I have my updates… full disclosure, I’m learning Go as I go through this, so feel free to provide suggestions please. 🙂 ---
**Author:** ![bendbennett](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/bendbennett/32/30764_2.png) [@bendbennett](https://discuss.hashicorp.com/u/bendbennett)\ **Post date:** [September 21, 2023, 7:38am UTC](https://discuss.hashicorp.com/t/http-provider-not-returning-location-in-response/58416/2 "2023-09-21T07:38:46Z")
Hi @Beany 👋 As you mentioned, the _http_ provider currently follows redirects. [RFC7321](https://datatracker.ietf.org/doc/html/rfc7231#section-6.4.3) 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](https://pkg.go.dev/net/http#Client) on the http client, as has been suggested in the [proposal](https://github.com/relvacode/terraform-provider-http/blob/feature/explicit-follow-redirects/internal/provider/data_source_http.go#L153C10-L153C23) linked from the [Do not follow HTTP redirects](https://github.com/hashicorp/terraform-provider-http/issues/170#top) issue that you mentioned. Perhaps it’s worth commenting on the [Do not follow HTTP redirects](https://github.com/hashicorp/terraform-provider-http/issues/170#top) 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. ---
**Author:** ![Beany](https://avatars.discourse-cdn.com/v4/letter/b/e8c25b/32.png) [@Beany](https://discuss.hashicorp.com/u/Beany)\ **Post date:** [September 21, 2023, 2:20pm UTC](https://discuss.hashicorp.com/t/http-provider-not-returning-location-in-response/58416/3 "2023-09-21T14:20:32Z")
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. 🙂 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.