Right now GET and CPING (as well as provider) is on my TODO, in fact, they are currently set as "unimplemented" although the hooks are there.
The main issue is that we need to worry about a (possibly) large response body and some method of checking against that. I have some ideas, but it's not as "easy" as it was using ap_expr. > On Jan 19, 2016, at 5:14 PM, Tim Bannister <is...@c8h10n4o2.org.uk> wrote: > > On 19 January 2016 19:01:12 GMT, Jim Jagielski <j...@jagunet.com> wrote: >> Okey dokey... this is quite functional at this stage. >> Right now we have: >> >> o TCP health checking (socket up/down) >> o HTTP OPTIONS checking >> o HTTP HEAD checking >> o Support for ap_expr against the response of >> the backend for OPTIONS/HEAD >> o Ability to add a URI to the worker's path for >> a "health check" URL (eg: /check/up.php) >> o Allow for a set number of successes or failures >> before enabling/disabling the worker. >> o Some basic balancer-manager view > > That looks really good. > > In the longer term, what do people think about the idea of supporting GET as > a health check method? > > “up.php” or whatever might supply a special response which an ap_expr checks > for. I've seen this approach used to protect against serving an apparently > healthy backend (2xx status) which is actually serving the wrong page, eg > “this domain is for sale!” > > > -- > Tim Bannister – is...@c8h10n4o2.org.uk
