hashicorp / hashicorp/terraform-plugin-sdk
Expose preconfigured http.Client
- Dominant language
- Go
- Stars
- 485
- Forks
- 244
- Avg merge
- 19h 57m
- Merged PRs (30d)
- 4
Description
Terraform end-users expect certain consistent behaviour, which Terraform will struggle to offer without exposing a preconfigured `http.Client` which all providers consume.
## Examples
1. `User-Agent` header with Terraform and provider versions in all requests
2. Proxy settings - https://github.com/hashicorp/terraform/issues/17386
3. SSH tunneling - https://github.com/hashicorp/terraform/issues/8367
Since SDK, i.e. provider would still be responsible for constructing the `http.Client` we'd likely need to expand the protocol to allow core communicating any proxy/tunnel settings and allow providers to pick it up. These features would also need to be implemented first in core.
We can however begin by building and exposing the preconfigured client and increasing adoption of it in the meantime.
## Extra Context
We used to expose a shared `http.Client`, but that piece of code was removed as part of transitioning to standalone SDK because it was too tightly coupled with `version` package:
https://github.com/hashicorp/terraform/blob/fa12e9f7d9913d5d7de2a10decf74d1cae0e62df/httpclient/client.go
Contributor guide
Research direction
Start by reviewing the historical httpclient/client.go implementation linked in the issue, then inspect how the standalone SDK currently constructs provider HTTP clients. Define the SDK and protocol boundaries needed to expose a preconfigured client, and consider the stated User-Agent, proxy, and SSH-tunneling requirements. Done means the client is exposed and providers can adopt it consistently.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- api, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100