Wrong target reported when using AutoDependencyTracking and HTTP_PROXY environment variable
See original GitHub issueFollow up after #689 and #692.
The problem still persists, that when using request library together with HTTP_PROXY setting, all dependency requests that go through proxy have target of 443 (this are https requests).
Options object in HttpDependencyParser._getUrlFromRequestOptions is of following structure:
{
host: "proxy-host",
port: 3128,
proxyAuth: null,
headers: {
Accept: "application/json",
host: "destination-host:443",
},
method: "CONNECT",
path: "destination-host:443",
agent: false,
}
And after url.parse
in line 141, the protocol is “destination-host” and host is 443.
Anyway - the result of _getUrlFromRequestOptions
function will be in this case still PROXY host, not the real one.
On the other hand, when I debug through public static trackRequest(client: TelemetryClient, telemetry: Contracts.NodeHttpDependencyTelemetry) {
I see requestParser.url set proxy host, but when callback is called telemetry.request.on('response', (response: http.ClientResponse) => {
then requestParser.url
is already set to target host and port, but without protocol. Can’t find place, where it’s actually changed.
Issue Analytics
- State:
- Created 3 years ago
- Comments:7 (4 by maintainers)
One question regarding migration to other libraries. As we will then use some other agent (that supports proxy), I’ve checked the node docs, and cant see that http.agent.protocol is part of the spec, so I fear, that whichever other library we will use, the above code will still fail, as other agents will also not provide this information.
On the other hand, I that recent versions of node (Added in: v14.5.0, v12.19.0) there is added field -
request.protocol
- maybe this is the place, where Azure Insights should also look. As far as I’ve tested (on v12.20.1), in both above cases request.protocol is set, though to this suspicious valuehttps:
(with colon at the end).Adding support for whatever is the current way of retrieving in native http/s make perfect sense, will update the code to use request.protocol as well when available