The issue is that I don't want to defer until an RPC is sent to tell the user something is wrong. This is part of an administration tool that has an explicit connect command and it would be good to fail then. Is there any sort of built in NULL rpc that can be used to test the connectivity or would I need to build that into my grpc definitions?
On Tuesday, June 18, 2019 at 2:04:33 PM UTC-6, Menghan Li wrote: > > If the connections fail because of TLS issues, the RPCs will also fail, > and the RPC errors will have the TLS error message. > > The PR https://github.com/grpc/grpc-go/pull/2055/ > <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fgrpc%2Fgrpc-go%2Fpull%2F2055%2F&sa=D&sntz=1&usg=AFQjCNElfr4RLPulZ9BrEx2qcqDf_9Id2A> > was > to get the underlying connection error after dialing, without making an > RPC. But we didn't get to finish the API design. > > On Monday, June 17, 2019 at 1:28:30 PM UTC-7, Dave Quigley wrote: >> >> The problem though is that is a configuration error. That is something >> that a user of the software would need to have an idea of what is going on >> to fix it and asking them to set the two environment variable and crawl >> through internal grpc debug messages. Also that won't catch if your >> certificates were not generated properly either. For example if you don't >> have the caRoot cert installed on your machine but your saying the >> certificates have to be verified. There was a pull request >> https://github.com/grpc/grpc-go/pull/2055/ that would introduce the >> ability to obtain the underlying network failure during a transient failure >> but it seems to be closed and has gone nowhere. It would really be useful >> for a person using grpc to develop a program to obtain this information so >> it can let the user know that they have a configuration issue. >> >> On Monday, June 17, 2019 at 1:04:06 PM UTC-6, Eric Anderson wrote: >>> >>> Correct. If the client expects TLS you will get an error if connecting >>> to a plaintext server. Some languages may provide more error information >>> than others, but in all language that information is intended for >>> developers, not programs to inspect. >>> >>> On Thu, Jun 13, 2019 at 12:00 PM Dave Quigley <[email protected]> wrote: >>> >>>> Hello, >>>> >>>> I have enabled TLS between a gRPC client and server and require client >>>> auth to be done as part of the exchange. I also have a flag to say that >>>> the >>>> server should be started without TLS securing the channel. However there >>>> does not seem to be a good way to figure out when connecting from a client >>>> that expects a TLS handshake that the reason it was unable to connect is >>>> that there is a mismatch of expectations. Am I missing something here? It >>>> seems that TLS handshake failures are just treated as transient failures >>>> and there is no way to get more details. >>>> >>>> Dave >>>> >>>> -- >>>> 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/f4429762-f894-42df-99a1-f7bdd5301390%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/grpc-io/f4429762-f894-42df-99a1-f7bdd5301390%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- 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/c424bda0-5f4e-43bc-8814-10532965d1d6%40googlegroups.com.
