grafana/synthetic-monitoring-agent

Http proxy requests can fail if they have to do DNS lookup

rdubrock opened this issue · 2 comments

rdubrock commented

I'm not 100% what's going on here, or if this is maybe use case specific. I'm just tossing this here as a placeholder until I can swing back a flesh it out.

To reproduce:

  • Create an http check pointed at a normal url (like http://www.google.com) with a proxy URL and auth header

What happened:

  • The probe fails

However, if you change the target from a URL like http://www.google.com to the IP address that the domain resolves to, it will work just fine.

mem commented

OK, this is weird.

adriansr commented

I submitted a patch that I think will solve this issue: #405

However, I'm not 100% what is causing the problem.

Without the patch, a proxied HTTPS request for google.com looks like:

CONNECT 216.58.215.142:443 HTTP/1.1
Host: 216.58.215.142:443
User-Agent: Go-http-client/1.1

And the SNI field in the TLS Client Hello is google.com.

(Note that the host field is wrong, should be google.com, and the User-Agent is also wrong)

Edit: This is correct, according to this discussion haproxy/haproxy#1159, the Host header must be equal to the target passed in the connect method. I still think the below is correct:

This sometimes works, sometimes doesn't, and sometimes results in a redirect that is requested as:

CONNECT google.com:443 HTTP/1.1
Host: google.com:443
User-Agent: Go-http-client/1.1

My understanding is that the proxy request is handled internally by either Go or prometheus/common and is not prepared to use the Host header that BBE injects after resolving the original hostname. Then we depend on how the target server responds to a request without the correct Host header.

The above patch is supposed to fix this as it disables all the magic around the hostname. The only drawback is that we're loosing the DNS metrics, but those doesn't make sense in a proxied request anyway.