HTTP/1.1 Host header replaced when dealing with SRV records in client

[uepoch]

Describe the bug
HTTP/1.1 RFC2616 specify that Host header should be set as the original input from the user so that virtual servers can be handled
When the hostname you pass in api's Client (affect CLI and golang projects) responds to SRV records, it will replace the Host header with any SRV record that is answered.
Code here

To Reproduce
Define a DNS setup with a name responding on SRV record (like what you could have with consul if you registered it as a service)

vault.consul.example.com 10 IN SRV 1 1 80 loadbalancer213.example.com

Have a loadbalancer configuration matching on Host header to load balance requests
Use the vault CLI to target it

Expected behavior
The Host header of the HTTP request should be vault.consul.example.com, as specified by the URL typed by the user
This would allow loadbalancers behind SRV records to be able to route properly requests to their backend

Environment:

• Vault Server Version (retrieve with vault status): Any
• Vault CLI Version (retrieve with vault version): Since 0.8.0
• Server Operating System/Architecture: Any

Additional context

• I would be happy to provide more precise traces in PM, to avoid disclosing our internal DNS infra
• SRV records are sometimes automatically created when dealing with dynamic (mesos,...) infrastructures, consul actually respond A,AAAA,SRV records for each service located inside.
• afaik, HTTP RFC does not specify how to handle SRV records
• Most clients honor this behavior when dealing with CNAME records

What do you think ?