Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Option to add proxy #166

Open
nkpanda opened this issue Jun 16, 2020 · 10 comments · May be fixed by #306
Open

Option to add proxy #166

nkpanda opened this issue Jun 16, 2020 · 10 comments · May be fixed by #306

Comments

@nkpanda
Copy link

nkpanda commented Jun 16, 2020

Is there any option to forward the traffic via any app proxy? This will help in easy edit of json requests and understanding of full http requests.
@jhump
Copy link
Contributor

jhump commented Jun 17, 2020

grpcurl does not implement the HTTP transport or gRPC protocol details. Instead, it relies on the grpc/grpc-go project for that.

Looking through proxy-related issues in that project (such as grpc/grpc-go#1446), it appears that a proxy can be used by simply setting environment variables. I will investigate and report back how to set that up.

However, that linked issue above does state some limitations with the support of proxies that will apply here.

@bbuckland
Copy link

@jhump Is there any update here? Trying to get grpcurl to proxy traffic through tools like Charles or Proxyman.

@jhump
Copy link
Contributor

jhump commented Mar 31, 2021

It looks like the Go runtime for gRPC, which is what grpcurl uses under its hood, supports environment variables in a similar fashion as curl and python: HTTP_PROXY, HTTPS_PROXY, and NO_PROXY can inform the program how to route a request through a proxy.

So I think the following might work. Please try it out:

HTTP_PROXY=127.0.0.1:8080 grpcurl ...

@jhump jhump mentioned this issue Mar 31, 2021
Closed
@terinjokes
Copy link

@jhump I've tried this with HTTP_PROXY and HTTPS_PROXY and neither changed the behavior of grpcurl. I can see with the output of ss -ntp | grep grpcurl that it continued to connect directly instead of using my SSH tunnel.

@Z5eyhS0uubejR0SVmX2O
Copy link

Z5eyhS0uubejR0SVmX2O commented Jun 4, 2021 •
edited

@jhump I've tried this with HTTP_PROXY and HTTPS_PROXY and neither changed the behavior of grpcurl. I can see with the output of ss -ntp | grep grpcurl that it continued to connect directly instead of using my SSH tunnel.

Same here:

$ docker run --rm -e HTTP_PROXY=127.0.0.1:1234 fullstorydev/grpcurl api.grpc.me:443 list
grpc.reflection.v1alpha.ServerReflection
listennotes.v1.Podcasts

$ docker run --rm -e HTTPS_PROXY=127.0.0.1:1234 fullstorydev/grpcurl api.grpc.me:443 list
grpc.reflection.v1alpha.ServerReflection
listennotes.v1.Podcasts

$ docker run --rm -e HTTPS_PROXY=127.0.0.1:1234 -e GRPC_GO_LOG_VERBOSITY_LEVEL=99 -e GRPC_GO_LOG_SEVERITY_LEVEL=info fullstorydev/
grpcurl api.grpc.me:443 list
INFO: 2021/06/04 20:00:29 [core] parsed scheme: ""
INFO: 2021/06/04 20:00:29 [core] scheme "" not registered, fallback to default scheme
INFO: 2021/06/04 20:00:29 [core] ccResolverWrapper: sending update to cc: {[{api.grpc.me:443  <nil> 0 <nil>}] <nil> <nil>}
INFO: 2021/06/04 20:00:29 [core] ClientConn switching balancer to "pick_first"
INFO: 2021/06/04 20:00:29 [core] Channel switches to new LB policy "pick_first"
INFO: 2021/06/04 20:00:29 [core] Subchannel Connectivity change to CONNECTING
INFO: 2021/06/04 20:00:29 [core] Subchannel picks a new address "api.grpc.me:443" to connect
INFO: 2021/06/04 20:00:29 [core] pickfirstBalancer: UpdateSubConnState: 0xc0003504d0, {CONNECTING <nil>}
INFO: 2021/06/04 20:00:29 [core] Channel Connectivity change to CONNECTING
INFO: 2021/06/04 20:00:29 [core] Subchannel Connectivity change to READY
INFO: 2021/06/04 20:00:29 [core] pickfirstBalancer: UpdateSubConnState: 0xc0003504d0, {READY <nil>}
INFO: 2021/06/04 20:00:29 [core] Channel Connectivity change to READY
grpc.reflection.v1alpha.ServerReflection
listennotes.v1.Podcasts
INFO: 2021/06/04 20:00:29 [core] Channel Connectivity change to SHUTDOWN
INFO: 2021/06/04 20:00:29 [core] Subchannel Connectivity change to SHUTDOWN

@Z5eyhS0uubejR0SVmX2O
Copy link

The proxy settings are overridden by the customized dialer:

	dialer := func(ctx context.Context, address string) (net.Conn, error) {
		// NB: We *could* handle the TLS handshake ourselves, in the custom
		// dialer (instead of customizing both the dialer and the credentials).
		// But that requires using WithInsecure dial option (so that the gRPC
		// library doesn't *also* try to do a handshake). And that would mean
		// that the library would send the wrong ":scheme" metaheader to
		// servers: it would send "http" instead of "https" because it is
		// unaware that TLS is actually in use.
		conn, err := (&net.Dialer{}).DialContext(ctx, network, address)
		if err != nil {
			writeResult(err)
		}
		return conn, err
	}

It looks like this is the recommended path to take for proxy setting administration according to grpc/grpc-go#1446
It just wasn't coded to support proxies.

@jhump
Copy link
Contributor

jhump commented Jun 14, 2021

@terinjokes and @Z5eyhS0uubejR0SVmX2O, thanks for trying it out. I'm sorry that didn't work.

I'll have to do more research to understand how to correctly do the proxying using a custom dialer and then figure out a way to test.

If you have the inclination to investigate and then implement and test a fix, I'd happily accept a pull request.

@joanbono
Copy link

Hi! Is there any option to implement this or it is not planned atm?

denysvitali pushed a commit to swisscom/grpcurl that referenced this issue May 3, 2022
feat: add support for HTTPS_PROXY
ea55023 
This commit adds support for the HTTPS_PROXY environment variable.
At the moment the NO_PROXY environment variable is ignored, please
be aware of that!

This should close fullstorydev#166
@denysvitali denysvitali linked a pull request May 3, 2022 that will close this issue
Open
@krugi
Copy link

krugi commented Feb 15, 2023 •
edited

Is there a plan to implement it?

@s4ke
Copy link

s4ke commented May 22, 2024

It would be great if this were supported. There already seems to exist a suitable PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat: add support for HTTPS_PROXY swisscom/grpcurl
8 participants
@terinjokes @s4ke @jhump @bbuckland @nkpanda @joanbono @krugi @Z5eyhS0uubejR0SVmX2O