Am 20.01.2016 um 01:57 schrieb Jim Jagielski:
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.
I wouldn't worry to much about the resource use in case of large
response bodies. As long as we warn in the docs. Most uses of this
advanced feature should end up using a special probing page in the
backend (application). GET instead of HEAD is nice though, because that
page can include some small status info which can be evaluated using the
expr.
Cool stuff!
Regards,
Rainer
On Jan 19, 2016, at 5:14 PM, Tim Bannister <[email protected]> wrote:
On 19 January 2016 19:01:12 GMT, Jim Jagielski <[email protected]> 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 – [email protected]
