-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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
proposal: net/http.Client should allow omitting URLs from error strings #44819
Comments
cc @ianlancetaylor as likely Proposal |
This seems related to This seems like a reasonable idea to me if you want to write a proposal. Thanks. |
@ianlancetaylor thank you for the quick reply; I can definitely work to reformat this issue into more of a proposal format. I've zero experience with that so I'll figure out how to do it right. To your comment, yeah it's definitely similar. In this case it was a query parameter that wouldn't be caught by that method, and so I was thinking it might be better to have a way to turn this functionality off versus trying to complicate the stdlib with some sort of programmer-supplied filter specification. I'll be sure to include that context in the reformat I do, to give others a concrete opportunity to challenge that assumption. Thanks again! |
@ianlancetaylor alrighty, I've reformatted the issue to be more proposal-like. If this format doesn't fit the bill give me a shout. |
One thing I considered when writing my proposal was to not have the bool on the |
This seems reasonable to me. |
You can do something like this to redact the URLs without requiring any changes to net/http (playground link - won't run on the playground because of #44822): func RedactErrorURL(err error) {
var ue *url.Error
if errors.As(err, &ue) {
ue.URL = "<redacted>"
}
} That works even when you don't have control over the |
@tmthrgd you are correct that is the solution you can pursue today. In the context section I mention the challenges of that approach:
|
But surely that’s no different at all to how easy it would be to forget to set the |
What about Notably, |
@bradfitz Considering the use case of wanting to retain the URL in the |
I guess a second question comes to mind, would we want that function to take an |
@bradfitz wanted to see if you'd had any spare cycles to noodle on the above. |
If we're willing to permit
This permits inspecting the original URL (by recovering the |
Context
When using a
net/http.Client
, especially with acontext.Context
that has a deadline, it’s not uncommon for thehttp.Client.Do()
method to return an error that contains the full URL used when actioning the request. Unfortunately that URL may contain sensitive query parameters, or other things that make it unsafe for directly logging or forwarding elsewhere without first sanitizing the URL or removing it entirely.There was a Gopher who recently ran into a case where they were almost writing sensitive URLs out to log files, but they managed to catch that in a pre-production environment. They could, at each
http.Client.Do()
call site, write logic to reformat the error value to not include the URL, but there are a few problems with that approach.The first is that you’d run the risk of forgetting to add that protection somewhere, or a code change / addition in the future could omit it. In addition if you’re mutating the error value to remove the URL, you’ve made it so that callers cannot inspect that detail of the error if they wanted to use it to decide to handle the error in a specific way.
Proposal
Considering the above context, I’d like to propose that we extend the
net/http.Client
to optionally omit the URL from any and all errors that get generated when it tries to action a request. This would allow programmers to set the behavior on the client itself, mitigating the first risk of forgetting to filter the URL from the error at a specific call site. This would be accomplished by adding abool
field to thenet/http.Client
struct:OnErrorOmitURL
. The zero value (false
) for this field would result in thehttp.Client
behaving like it does today, meaning this would not be a breaking change.Because the errors returned from the
http.Client.Do()
method are of typenet/url.Error
, we will also need to extend that type to include a bool struct field,OmitURL
, which results in theError()
method not including the URL in the error string it returns. This will address the second risk above as the URL will still be present in string form within theurl.Error.URL
field, but it won’t be implicitly included when the error value is printed or logged. Like the field on thenet/http.Client
, the zero value (false
) will result inurl.Error
working like it does today, meaning this would also not be a breaking change.The text was updated successfully, but these errors were encountered: