fullstorydev / grpcurl

Like cURL, but for gRPC: Command-line tool for interacting with gRPC servers

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Add support for subdirectories in request path

d1820 opened this issue · comments

Seems GrpCurl is missing support for being able to add a sub directory for the request call.

Tried

  • Adding to address param (obv throws an error)
  • Adding as fully qualified symbol is not supported
  • Adding as a customer header for :path does not work

Maybe i am not doing it correctly but nothing here seems to work

option 1

./grpcurl -plaintext -vv -v -proto ./linuxcode/api.proto -H "Authorization: Bearer ey..." -d '{"RegionName":"Dev","ResourceName":"Test"}' "internal.company.net:5050/platform/" "Settings.GetSettings"

option 2

./grpcurl -plaintext -vv -v -proto ./linuxcode/api.proto -H "Authorization: Bearer ey..." -d '{"RegionName":"Dev","ResourceName":"Test"}' "internal.company.net:5050" "platform/Settings.GetSettings"

option 3

./grpcurl -plaintext -vv -v -proto ./linuxcode/api.proto -rpc-header ':path: platform' -H "Authorization: Bearer ey..." -d '{"RegionName":"Dev","ResourceName":"Test"}' "internal.company.net:5050" "Settings.GetSettings"

option 1

./grpcurl -plaintext -vv -v -proto ./linuxcode/api.proto -H ':path: platform' -H "Authorization: Bearer ey..." -d '{"RegionName":"Dev","ResourceName":"Test"}' "internal.company.net:5050" "Settings.GetSettings"

Any help or in site to this being a bug would be great.

Background
in our .net core application to get it all working correctly we inject a custom httpHandler that appends the subdirectory to the outgoing request to the GRPC service. This all works and is actually presented as the way by Microsoft: https://docs.microsoft.com/en-us/aspnet/core/grpc/troubleshoot?view=aspnetcore-6.0#calling-grpc-services-hosted-in-a-sub-directory

Yeah, that's a pretty non-standard situation. Even in the doc you linked:

The address path is ignored because gRPC has a standardized, prescriptive address structure. A gRPC address combines the package, service and method names: https://localhost:5001/PackageName.ServiceName/MethodName.

Bummer. So what is the prescribed way of hosting in production? Dedicated subdomains?

@lucasmaj that is the direction we ended up taking.. we rolled back all our . net code for sub directories and switched to domains

Bummer. So what is the prescribed way of hosting in production? Dedicated subdomains?

@lucasmaj, @d1820, do you mean for backend routing, like through a reverse proxy? If so, you could configure different backend routes based on the service names -- so still using paths, just not custom path prefixes.

@lucasmaj, @d1820, do you mean for backend routing, like through a reverse proxy? If so, you could configure different backend routes based on the service names -- so still using paths, just not custom path prefixes.

That is exactly what I just figured out. Effectively, ingress routes based on gRPC service package name. I am going with this approach while I am waiting for subdomains/dns entries.