Pseudo-patch... that is.
> On Jan 20, 2016, at 11:31 AM, Jim Jagielski <j...@jagunet.com> wrote:
>
> From what I can see, this is the full patch required (minus docs):
>
> diff --git a/server/util_expr_eval.c b/server/util_expr_eval.c
> index 5a8f207..e97df88 100644
> --- a/server/util_expr_eval.c
> +++ b/server/util_expr_eval.c
> @@ -1049,6 +1049,25 @@ static const char *req_table_func(ap_expr_eval_ctx_t
> *ctx, const void *data,
> return apr_table_get(t, arg);
> }
>
> +static const char *kb_func(ap_expr_eval_ctx_t *ctx, const void *data,
> + const char *arg)
> +{
> + apr_off_t *length;
> + apr_status_t rv;
> + const char *buf;
> +
> + if (!ctx->r || !ctx->r->kept_body)
> + return "";
> +
> + rv = apr_brigade_length(ctx->r->kept_body, 1, &length);
> + if (rv != APR_SUCCESS || length == 0)
> + return "";
> +
> + buf = apr_palloc(ctx->r->pool, length+1);
> + apr_brigade_flatten(ctx->r->kept_body, buf, length);
> + return buf;
> +}
> +
> static const char *env_func(ap_expr_eval_ctx_t *ctx, const void *data,
> const char *arg)
> {
> @@ -1785,6 +1804,7 @@ static const struct expr_provider_single
> string_func_providers[] = {
> { unbase64_func, "unbase64", NULL, 0 },
> { sha1_func, "sha1", NULL, 0 },
> { md5_func, "md5", NULL, 0 },
> + { kb_func, "kept_body", NULL, 0 },
> #if APR_VERSION_AT_LEAST(1,6,0)
> { ldap_func, "ldap", NULL, 0 },
> #endif
>
> in other words, pretty brain dead easy...
>
>
>> On Jan 20, 2016, at 11:11 AM, Rainer Jung <rainer.j...@kippdata.de> wrote:
>>
>> Am 20.01.2016 um 16:28 schrieb Jim Jagielski:
>>>
>>>> On Jan 20, 2016, at 9:57 AM, Jim Jagielski <j...@jagunet.com> wrote:
>>>>
>>>> It would *REALLY* be nice if ap_expr was r->kept_body
>>>> aware.
>>>>
>>>
>>> Actually, that does NOT look that difficult...
>>>
>>> Comments? Should I go for it?
>>
>> No personal preference. The expression parser until now mostly is used on
>> the request side, so there's no immediate reuse of making it response aware.
>> So I'd decide on how much it distracts you from HC. Simply implementing a
>> dirty workaround for HC should be fine as well. Those requests do not run
>> with very high frequency (<< 100/s).
>>
>> Regards,
>>
>> Rainer
>>
>>>> I could look at folding that in, but my goal is that all the
>>>> health-check stuff is 2.4-backport-able, and don't want to
>>>> hack ap_expr to allow that and have someone block that backport
>>>> due to, well... whatever. Some people just like blocking back-
>>>> ports, especially from people who's 1st and last names have the
>>>> same letters :)
>>>>
>>>>> On Jan 20, 2016, at 8:08 AM, Jim Jagielski <j...@jagunet.com> wrote:
>>>>>
>>>>>>
>>>>>> On Jan 20, 2016, at 7:59 AM, Jim Jagielski <j...@jagunet.com> wrote:
>>>>>>
>>>>>>>
>>>>>>> On Jan 20, 2016, at 3:34 AM, Rainer Jung <rainer.j...@kippdata.de>
>>>>>>> wrote:
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>
>>>>>> The only thing I can't figure out yet is that ap_expr doesn't
>>>>>> seem to be able to work on the response *body*, at least,
>>>>>> I haven't seen where it is able to do so. So I'll need to figure
>>>>>> out how to "trick" it to do so.
>>>>>
>>>>> I guess I could shove the response body in the request note
>>>>> array... let me see.
>
