You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
gRPC's call options, which are passed to stub interfaces, are opaque. This prevents a custom transport implementation from examining them and properly acting on them.
In particular, this means that a unary method invocation cannot get response headers since that is done via call options. There is an issue tracking this API deficiency in the grpc-go repo: grpc/grpc-go#1495
There is a similar issue in the server-side. Attempts to send response headers from unary handlers that are invoked from a custom transport implementation will always return an error. This is because the grpc.SetHeader (and company) methods are expecting to find a *transport.Stream in context (which is put there by the HTTP/2 transport implementation). But no API is exposed to allow custom transports to do something similar. This issue is also being tracked in the grpc-go repo: grpc/grpc-go#1802
This grpchan bug will persist until these issues are addressed.
I happen to have two open pull requests which would address them. I am hoping they will be accepted: grpc/grpc-go#1902 and grpc/grpc-go#1904.
The text was updated successfully, but these errors were encountered:
gRPC's call options, which are passed to stub interfaces, are opaque. This prevents a custom transport implementation from examining them and properly acting on them.
In particular, this means that a unary method invocation cannot get response headers since that is done via call options. There is an issue tracking this API deficiency in the grpc-go repo: grpc/grpc-go#1495
There is a similar issue in the server-side. Attempts to send response headers from unary handlers that are invoked from a custom transport implementation will always return an error. This is because the
grpc.SetHeader
(and company) methods are expecting to find a*transport.Stream
in context (which is put there by the HTTP/2 transport implementation). But no API is exposed to allow custom transports to do something similar. This issue is also being tracked in the grpc-go repo: grpc/grpc-go#1802This grpchan bug will persist until these issues are addressed.
I happen to have two open pull requests which would address them. I am hoping they will be accepted:
grpc/grpc-go#1902 and grpc/grpc-go#1904.
The text was updated successfully, but these errors were encountered: