Support proxy

[menghanl]

Support TCP-level proxies via the HTTP CONNECT request.

Implementes gRFC A1: grpc/proposal#4.

[mwitkow]

Go already has an abstraction of net.Dialer which can be usedto address both points of the https://github.com/grpc/proposal/pull/4/files proposal: allowing to overwrite the address and perform TCP-level operations before handing off to gRPC. Can we please use that instead to make the library more Go-canonical and just write sugar-APIs on top to make it look like gRPC C++?

We had exactly the same problem: dialing remote gRPC endpoints over HTTPS connect. We've built https://github.com/mwitkow/go-http-dialer and end-to-end integraiton tests gRPC plaintext and gRPC tls https://github.com/mwitkow/go-http-dialer/blob/master/test/grpc_e2e_test.go

[menghanl]

In the proposal, it's proposed that we need to kinds of mapping functions, MapName before name resolution and MapAddress after name resolution.

Custom dialer only works in the case of MapAddress.
If the name cannot be resolved, dialer won't work.

[mwitkow]

The dialer gets the hostname in single connection mode so you definitely can mapname as well (that's what we do). Unless you're taking of mapname before hitting grpc.Naming then you're right. But few people would be using Grpc.Naming and grpc LB with a proxy connection.

…

On Tue, 28 Feb 2017, 18:23 Menghan Li, ***@***.***> wrote: In the proposal, it's proposed that we need to kinds of mapping functions, MapName before name resolution and MapAddress after name resolution. Custom dialer only works in the case of MapAddress. If the name cannot be resolved, dialer won't work. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1095 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJNWoyK3e-xGVs8BB-p7DNkamKaNLa8sks5rhGYzgaJpZM4MNw9W> .

[menghanl]

Make sense.
Close this and added #1098