+Jiangtao and +Vijay Would it be feasible to expose TLS failures in the gRPC core stack somehow? Even if they weren't recoverable.
On Fri, May 25, 2018 at 6:16 PM Russ Allbery <[email protected]> wrote: > "'Carl Mastrangelo' via grpc.io" <[email protected]> writes: > > > At least in the Java world, connections are treated as a queue of > > handlers, with TLS near the network side. Any TLS failures are not > > surfaced (or not easily anyways) since they never make it up to the gRPC > > layer. Gather these stats server side would require some code changes. > > I know you said you are using python, but I think every language would > > be able to benefit from knowing about such failures. > > Yeah, agreed, it just so happens that my specific problem is with Python > and Go. Go is relatively straightforward to implement without making > changes to gRPC because (for various other reasons) we're already hooking > into the TLS negotiation and that's exposed fairly well with a few > strategic proxy objects. But the C/C++ native code is a bit less amenable > to that. > > I assume client-side poses similar challenges? Or is it easier to hook > into? > > -- > Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> > -- 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAAcqB%2BvmKKt%3D0Y%2BmRbL1RwMH5jB%3Dte5VR5fk1LHYHYMmUgwfcQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
