Committed revision 1725755.
> On Jan 20, 2016, at 11:37 AM, Jim Jagielski <j...@jagunet.com> wrote:
>
> 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.
>>
>
