-
Notifications
You must be signed in to change notification settings - Fork 118
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
v3.2.0 No Longer Supports Proxy Settings #198
Conversation
@@ -163,6 +163,7 @@ func (d *httpDataSource) Read(ctx context.Context, req datasource.ReadRequest, r | |||
caCertificate := model.CaCertificate | |||
|
|||
tr := &http.Transport{ | |||
Proxy: http.ProxyFromEnvironment, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this is the most complete way to handle behavior differences that were introduced in v3.2.0, as the Proxy is only one of several properties that are set on the DefaultTransport (https://github.com/golang/go/blob/f3c39a83a3076eb560c7f687cbb35eef9b506e7d/src/net/http/transport.go#L38-L54) that are no longer going to be consistent with the previous version behavior. Ignoring the proxy values was the most immediately noticeable to users, but what about all of the timeouts, MaxIdleConns
, and ForceAttemptHTTP2
which will also default to different values than those from older provider versions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would also recommend using http.DefaultTransport
to prevent other potential behavior changes. There could also be consideration for using https://pkg.go.dev/github.com/hashicorp/go-cleanhttp similar to other HashiCorp maintained Go modules to prevent potential issues with multiple host connections across data sources or other regressions involving a mutated http.DefaultTransport
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have switched to using http.DefaultTransport
. I took a look at https://pkg.go.dev/github.com/hashicorp/go-cleanhttp but it seems that there are differences in the configuration of the Transport
so in order to avoid changes in behaviour this has not been used at this time.
p := goproxy.NewProxyHttpServer() | ||
|
||
proxy := httptest.NewServer(p) | ||
defer proxy.Close() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Over in the terraform-provider-tls acceptance testing, all the testing HTTP servers, including the proxies, have connection counting:
Then there is a TestCheckFunc
which ensures that the "real" HTTP server and proxy HTTP server have matching connection counts:
I think we'll need something similar here to verify that the proxy is correctly being used, unless there is a better testing strategy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm looking into the current test failures (e.g., https://github.com/hashicorp/terraform-provider-http/actions/runs/3376234811/jobs/5603729486).
Check 2/2 error: expected server and proxy active connection count to match: server was 1, while proxy was 0
I can't reproduce this failure locally, I see a different failure.
Check 2/2 error: expected server and proxy active connection count to match: server was 3, while proxy was 1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see the same failures in CI (e.g., https://github.com/hashicorp/terraform-provider-http/actions/runs/3376368850/jobs/5604018894) when using
tr := &http.Transport{
Proxy: http.ProxyFromEnvironment,
}
Check 2/2 error: expected server and proxy active connection count to match: server was 1, while proxy was 0
But all tests pass when running locally with this configuration.
@@ -163,6 +163,7 @@ func (d *httpDataSource) Read(ctx context.Context, req datasource.ReadRequest, r | |||
caCertificate := model.CaCertificate | |||
|
|||
tr := &http.Transport{ | |||
Proxy: http.ProxyFromEnvironment, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would also recommend using http.DefaultTransport
to prevent other potential behavior changes. There could also be consideration for using https://pkg.go.dev/github.com/hashicorp/go-cleanhttp similar to other HashiCorp maintained Go modules to prevent potential issues with multiple host connections across data sources or other regressions involving a mutated http.DefaultTransport
.
url = "%s" | ||
} | ||
`, svr.URL), | ||
Check: resource.TestCheckResourceAttr("data.http.http_test", "status_code", "200"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test looks correct to me, but for some reason is unhappy on Terraform version 0.14:
=== RUN TestDataSource_HTTPViaProxyWithEnv
data_source_http_test.go:489: Step 1/1 error: Check failed: Not found: data.http.http_test in [root]
--- FAIL: TestDataSource_HTTPViaProxyWithEnv (0.40s)
I'll try to do some investigative work with my end of day.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The quirk with Terraform version 0.14.x is that it will not set the Terraform state for a data source which returns a warning diagnostic. The warning being generated here is:
2022-11-01T16:50:56.310-0400 [TRACE] sdk.proto: Received downstream response: diagnostic_error_count=0 diagnostic_warning_count=1 tf_req_duration_ms=0 tf_data_source_type=http tf_req_id=5887d459-0e1a-5aa1-0241-13d21f8698ca tf_provider_addr=registry.terraform.io/hashicorp/http tf_proto_version=5.3 tf_rpc=ReadDataSource
2022-11-01T16:50:56.310-0400 [WARN] sdk.proto: Response contains warning diagnostic: tf_provider_addr=registry.terraform.io/hashicorp/http tf_proto_version=5.3 tf_rpc=ReadDataSource tf_data_source_type=http diagnostic_severity=WARNING diagnostic_summary="Content-Type is not recognized as a text type, got \"\"" diagnostic_detail="If the content is binary data, Terraform may not properly handle the contents of the response." tf_req_id=5887d459-0e1a-5aa1-0241-13d21f8698ca
2022-11-01T16:50:56.310-0400 [TRACE] sdk.proto: Served request: tf_provider_addr=registry.terraform.io/hashicorp/http tf_proto_version=5.3 tf_rpc=ReadDataSource tf_data_source_type=http tf_req_id=5887d459-0e1a-5aa1-0241-13d21f8698ca
The data source correctly does not exit early in this case. The testing fix for this is to ensure the HTTP response also includes a valid Content-Type
header, e.g.
svr := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "text/plain")
w.WriteHeader(http.StatusOK)
}))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the investigation. Have added the fix you suggested.
…st failures are attributable to using http DefaultTransport (#197)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One more little consideration, otherwise looks good to me 🚀
return httpproxy.FromEnvironment().ProxyFunc()(req.URL) | ||
} | ||
|
||
if clonedTr.TLSClientConfig == nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: To further prevent any differences due version to 3.2.0 changes, it is mentioned in the TLSClientConfig
documentation that:
// If nil, the default configuration is used.
// If non-nil, HTTP/2 support may not be enabled by default.
I think we may want to consider moving this nil
check inside each of the !IsNull()
branches below to prevent any sort of further HTTP/2 oddities when there is no custom TLS configuration.
My editor is also prompting to run |
Any date in mind for the release of the fix ? Thx in advance |
Co-authored-by: Brian Flad <bflad417@gmail.com>
Hi @RaphaelDucay 👋 |
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
Closes: #197