Reference upstream by id (not URL) in connector error messages#244
Merged
Conversation
HttpConnector wrapped the raw *url.Error from failed upstream requests into the client-facing ResponseError. That string embeds the full upstream URL - both any credential in its path/query (e.g. /v2/<key>, ?dkey=<key>) and the host itself, which is infrastructure disclosure. The ctx-cancelled branches and the "invalid upstream url" client-failure paths leaked it too. Tag each HttpConnector with its upstream id (threaded through the factory) and make every connector failure path reference the upstream by id only. The full URL is logged for operators (zerolog) but never returned to the caller. Covered by a connector test that fails if the key OR the host survives in the client-facing error.
a10zn8
reviewed
Jul 17, 2026
| return newHttpConnectorWithId(connectorConfig, specs.RestConnector, torProxyUrl, upId) | ||
| case specs.RestAdditional: | ||
| return connectors.NewHttpConnector(connectorConfig, specs.RestAdditional, torProxyUrl) | ||
| return newHttpConnectorWithId(connectorConfig, specs.RestAdditional, torProxyUrl, upId) |
Contributor
There was a problem hiding this comment.
Maybe just add up id to NewHttpConnector ?
Drop the WithUpstreamId builder method and the newHttpConnectorWithId factory helper; both constructors now take upstreamId directly.
a10zn8
approved these changes
Jul 18, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When an upstream request fails at the connection layer (DNS failure, connection refused/reset, TLS error, timeout),
http.Client.Doreturns a*url.ErrorwhoseError()embeds the full upstream URL — both any credential carried in its path/query (e.g./v2/<key>,?dkey=<key>) and the host itself.HttpConnectorwrapped that raw error verbatim into the client-facingResponseError, so the URL could surface to the caller. The ctx-cancelled branches and the "invalid upstream url" client-failure paths leaked it the same way.Fix
Tag each
HttpConnectorwith the id of the upstream it serves (threaded through the connector factory), and make every connector failure path reference the upstream by id only:upstream <id> request failedunable to read response from upstream <id>invalid url for upstream <id>upstream <id>: context canceledThe full URL is still logged for operators (zerolog), but never returned to the caller.
Tests
A connector test drives a connection failure and asserts the client-facing error references the upstream id while neither the API key nor the host survives in it.