Support issuing requests to a known SocketAddr

[Ralith]

Client currently only supports issuing requests to Uris (which must be parsed from strings), and automatically performs DNS resolution on them. While this is convenient, in some applications the exact address of the remote host is already known. For those cases, passing in a SocketAddr directly would be considerably less error-prone and more efficient.

[sfackler]

You can stick the IP address into the URI and no DNS resolution will be performed.

[Ralith]

Sure, but this is Rust; we shouldn't have to round-trip that information through a string.

[seanmonstar]

1. I mentioned in feat(client): make dns resolver pluggable #1174 that we're probably under-utilizing the ClientProto onion, which should probably allow getting a transport from anywhere, and into hyper's Client. If we can figure out how to improve on that without breaking changes to tokio or hyper, we could move towards that within hyper 0.11!
2. I really want number 1 to happen, but for the moment, the string conversion and back is pretty small compared to the network IO.

---

Would it make sense to repurpose this issue to track what I said about the ClientProto onion?

[Ralith]

I really want number 1 to happen, but for the moment, the string conversion and back is pretty small compared to the network IO.

It's not about performance so much as robustness. There are far fewer moving parts if you keep data in its native format.

Would it make sense to repurpose this issue to track what I said about the ClientProto onion?

If you think that's the way to go and it subsumes this specific concern, I have no objection to that.

[seanmonstar]

I've given this some more thought, and don't see a solution to this, really.

Assuming the server identifies as the socket address, the string version needs to be sent as the Host header in HTTP/1, and as the :authority header in HTTP/2. If the server identifies as a domain instead, then you need to include the domain in the Uri so hyper can write it. Either way, a Uri is needed.

Considering that, and that resolving and connecting to a socket isn't actually something hyper is particularly interested in (it just wants to implement HTTP over some IO object, connectors can be implemented to do anything), I don't see a specific problem that this issue would be solving.