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 <[email protected]> wrote:
>
> Am 20.01.2016 um 16:28 schrieb Jim Jagielski:
>>
>>> On Jan 20, 2016, at 9:57 AM, Jim Jagielski <[email protected]> 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 <[email protected]> wrote:
>>>>
>>>>>
>>>>> On Jan 20, 2016, at 7:59 AM, Jim Jagielski <[email protected]> wrote:
>>>>>
>>>>>>
>>>>>> On Jan 20, 2016, at 3:34 AM, Rainer Jung <[email protected]> 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.
