grpc-kotlin
grpc-kotlin copied to clipboard
grpc
Metadata / Headers cannot be set in client stub
The change in Client stub should not take Metadata headers parameter #47 sets Metadata to Metadata() which prevents sending headers from the kotlin client stub to the server at all.
In the usual "grpc world" there are use cases for that. Simplest one is authentication by sending an "authorization" header to the server (e.g. JWT Token).
Either the optional header / metadata parameter is included in the stub again or it should at least allow the grpc client interceptors to set it.
see io.grpc.stub.attachHeaders(T stub, Metadata extraHeaders) from the java impl for the the complete chain.
I totally agree. I'm also pretty confused as to why this has been removed in the first place. Agreed that header are usually generic building blocks, for which interceptors might make more sense, but in the cases where you want to have more fine grained control over setting the headers, the current situation is too hard to be really usable.
Is it possible to re-add the metadata to the method signature, in the way as is has been before #47 ?
As @jankeesvanandel mentioned, fine-grained control is no more possible. I have a use case where I need a distinct header value for each request (a distinct request ID). Having the ability to set specific headers in each call was perfect and it can be found in most grpc client implementations. Right now, the only way I could make it work is to create a new stub for each request (which is definitely not the intended usage). I would highly recommend to put back the headers in each call or to provide an easy way to define headers on a per-request basis.
Any suggestions to solve this issue ?
I have also run into this problem. Which latest version of Kotlin stub contains metadata as parameter?
I am also facing the same issue. adding the "authorization" header but not being received by the server.
Sorry for being a party pooper, but this issue does not paint an accurate picture of where things are at. grpc-kotlin retains the ability from grpc-java to set CallOptions on the stub at the call site, which can then be transformed to Metadata via a ClientInterceptor and passed to the server, the same way it is done in grpc-java. I felt alarmed by this issue, so I specifically tested this approach, and it works fine.
I wouldn't say it's a nice approach, and you may need to use "unstable" APIs, but I believe this has been the standard makeshift solution for years. More recently the approach to authentication has been changing in grpc-java, so there may be better ways for the authentication use case altogether.
Looks like the tide on this issue has been shifting with the recent PR. Unsure if it's a good change, for the reason given in #47, and because of the recent authentication changes in grpc-java, which should trickle down to grpc-kotlin, but maybe there are unmentioned use cases where this is truly needed.
