Hi Bhaskar, On Fri, Feb 07, 2014 at 06:33:10PM -0500, Bhaskar Maddala wrote: > Hello, > > I apologize for my persistence and realize that everyone if busy with > getting > 1.5 out of the door. I have no expectations on that front for the patch > included > here. However any feedback is welcome. I went thru some of the submitted > patches and saw one by Simon Horman to use an external process after I > made this change and will revisit that again. > > I re-did my implementation, and this time I am submitting it as a patch for > consideration. I am posting the commit message that explains the change.
This is interesting. Today we had a discussion with Baptiste about how to make http checks work more like tcp checks (ie: have sequences of multiple checks) and we first spotted the need to be able to specify *some* common information (eg: some headers, etc) and some server-specific information. So between what you proposed and this discussion, we're starting to see some pieces that start to make the puzzle. In my opinion, we'd have to cover the ability to perform multiple requests to a server, by forcing or not an address (eg: http-check connect), by passing headers with a value from the server, or by passing raw headers, by passing cookies from responses to requests when using the same host header (useful to authenticate to a server), and possibly some other stuff. I think it's too early to decide on an implementation, but we could possibly first try to define a roadmap so that once we know what we want for the long term, we can start with a subset which will remain compatible with future versions (for example we don't need to support cookies right now). I think that for your current needs, we'd need at least a "check-name" directive on the servers to force the server name, which would default to the server's name in the configuration, and which would automatically be sent along with the Host header if some http-check directive is set (eg: "http-check set-host" with no argument). The other http-check rules were made to be reusable, and I think they will be. We just need to complete them. I don't think this is something we should merge before 1.5-final, but I do think that we'll quickly be able to test it in 1.6-dev and get enough feedback so that at one point if we trust the feature enough and it requires few changes, we'll be able to backport it into 1.5. > > ================================================================= > We add new directives to the http-check keyword > > The server option is used to specify an external > health checking server to use for health checks. > > Example: > http-check server <ipv4|ipv6> Please take a look at the "tcp-check connect" directive in the most recent snapshot. By default it just connects. You can specify a port (reusing the server's address) and we'll soon support an address. If the directive is not there, the check is sent to normal server's addr:port. We should try to standardize these things as much as possible so that people don't confuse them as we do between tcp-request and http-request which don't use the exact same actions for the same things (eg: deny vs reject). I'm even wondering whether we should not use a special "send" directive for http-check to indicate when to send versus when to prepare things. But that could be a bit awkward and confusing. Just thinking loud... Cheers, Willy
