exceptionfactory commented on pull request #4603: URL: https://github.com/apache/nifi/pull/4603#issuecomment-711109774
> > The concept of a health check for deployment behind a load balancer is useful, but listening on a different port and having a different approach to TLS negotiation may not be the most intuitive or generally applicable implementation. Is there a specific reason that the health check port should not follow the same TLS negotiation requirements as the primary port? More importantly, listening on a different port could introduce other complications. For example, a firewall between the load balancer and ListenHTTP would have to allow both the primary port as well as the health check port. Some load balancing servers perform health checks on the same port as the one configured for primary communication, so that seems like a better implementation approach. > > Main reason, I think, is in case the processor is configured with 2-ways SSL. Many load balancers cannot provide a client certificate for a health check. That's a good point, and probably more common than being limited to HTTP 200 for successful responses. As mentioned, there still seem to be some complicating factors with using an alternate port for checking health status. If there is interest in moving this feature forward with a separate port for health checks, having one additional property for Health Check Client Authentication, using the available values of NONE, WANT, and REQUIRED would avoid hard-coding a particular implementation. Depending on the network layout between the load balancer and the NiFi servers, it may be desirable to limit access based on an X.509 certificate that the load balancer provides. It could also be useful to allow unauthenticated health checking, so providing an option with sensible defaults would address both potential use cases. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
