On Mon, Nov 15, 2021 at 8:38 AM Christopher Meiklejohn < [email protected]> wrote:
> Last week, I was trying to attach a metadata header in a ClientInterceptor > that was a function of the message body -- but, also ran into the similar > problem that the start callback (where headers can be manipulated and are > transmitted) are handled before the message is. > I think this is a different issue. There are some similarities, but the details end up mattering quite a bit and in practice these end up looking different on client-side than server-side. In these cases you need to buffer the newCall()/start() until you have the data you need and then issue the RPC. Or you don't try to do this within an interceptor and have the application use something like MetadataUtils.newAttachHeadersInterceptor(). The best I can tell is that this is done to support the streaming API > internally (even if performing a unary call) where, the sendMessage > function, will be executed multiple times for each transmitted message, > after the headers are sent. > Yes. There is only one API and only the MethodDescriptor mentions whether the call is unary or streaming. The implementation behavior can be different in those cases, though, as for unary the gRPC library can buffer the request headers and message until it gets the halfClose. But that is more of a performance cut-out. Presumably, this is the same for the ServerInterceptor, where the headers > will be sent before the response. > Yes, although there's two things that make it different: 1. It sounds like the problem was whether the headers were sent before the *request* was received, which is possible but generally not the case. (This was actually recently fixed <https://github.com/grpc/grpc-kotlin/pull/275> in grpc-kotlin.) 2. You can't modify interceptors on server-side per-RPC, like you can on client-side. So this makes the MetadataUtils pattern unhelpful. For (2), it is possible to get similar functionality, but the approach turns out pretty different and is less obvious. This doesn't happen often, although if it did happen more frequently we'd have a utility for it. -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oPiTdqBFVSUHDikJ7n1ia-236A%3DsObb2t6S%3DO7R-LjqBA%40mail.gmail.com.
