This looks wrong:
case AP_EXPR_FUNC_STRING:
/* Function HC() is implemented by us.
*/
if (strcasecmp(parms->name, "HC") == 0) {
*parms->func = hc_expr_func_fn;
*parms->data = NULL;
return OK;
}
break;
Specifically:
*parms->data = NULL;
> On Jan 21, 2016, at 1:08 PM, Jim Jagielski <[email protected]> wrote:
>
> That is with:
>
> ProxyHCExpr foof2 {hc('body') !~ /domain is established/}
>
> With
>
> ProxyHCExpr foof2 {kept_body('body') !~ /domain is established/}
>
> it works as expected.
>
> Thx!
>> On Jan 21, 2016, at 1:06 PM, Jim Jagielski <[email protected]> wrote:
>>
>> I get:
>>
>> AH00102: [Thu Jan 21 18:05:44 2016] file util_expr_eval.c, line 218,
>> assertion "data != ((void*)0)" failed
>>
>>
>>> On Jan 21, 2016, at 12:50 PM, Rainer Jung <[email protected]> wrote:
>>>
>>> Am 21.01.2016 um 17:55 schrieb Jim Jagielski:
>>>> even better!
>>>>
>>>> sounds cool.
>>>
>>> First impl done in r1726038.
>>>
>>> I guess you have everything in place to do a quick test? That would be nice.
>>>
>>> svn log is:
>>>
>>> Implement expr lookup in mod_proxy_hcheck for
>>> variables whose names start with "HC_" and for
>>> the new function hc().
>>>
>>> Currently only HC_BODY and hc(body) are supported.
>>> Both return the saved body of the health check
>>> response to be used in an expr that decides about
>>> success of a check.
>>>
>>> Regards,
>>>
>>> Rainer
>>>
>>>>> On Jan 21, 2016, at 11:51 AM, Rainer Jung <[email protected]> wrote:
>>>>>
>>>>> Am 21.01.2016 um 17:03 schrieb Jim Jagielski:
>>>>>> Did you want me to work on it, or are you?
>>>>>
>>>>> I just had some late lunch and started to think closer about it. Since
>>>>> kept_body was previously only used for request bodies, wouldn't it be
>>>>> nicer to *not* expose the HC response body under that name in the
>>>>> expression parser, and instead register an expr extension from HC which
>>>>> handles a new function, say hc(), with a first supported argument "body"?
>>>>> So hc(body) returns whatever HC wants to.
>>>>>
>>>>> You could still use the kept_body field in your impl (or some other place
>>>>> now or later) but we wouldn't expose this implementation detail to the
>>>>> outside world.
>>>>>
>>>>> I have already done an expr function extension in some custom module, it
>>>>> is pretty easy to do (and httpd uses that feature e.g. in mod_ssl).
>>>>>
>>>>> So yes, if you like I can do it. But do you like the idea?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Rainer
>>>>>
>>>>>>> On Jan 21, 2016, at 10:25 AM, Jim Jagielski <[email protected]> wrote:
>>>>>>>
>>>>>>> Sounds good to me!!
>>>>>>>
>>>>>>> thx!
>>>>>>>
>>>>>>>> On Jan 21, 2016, at 10:23 AM, Rainer Jung <[email protected]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I should have asked earlier: wouldn't it be more suitable to implement
>>>>>>>> to response body as a variable instead of a function?
>>>>>>>>
>>>>>>>> When looking at server/util_expr_eval.c, I find request_var_names and
>>>>>>>> request_var_fn. The former is a list of variable names, and the latter
>>>>>>>> implements returning the values from parts of the request struct.
>>>>>>>> Returning the flattened kept_body should be a good fit there as well,
>>>>>>>> without having users wonder, why it is a function that requires an
>>>>>>>> argument.
>>>>>>>>
>>>>>>>> If we expect further response stuff coming, we could also clone
>>>>>>>> request_var_names and request_var_fn with new response_var_names and
>>>>>>>> response_var_fn and add the variable as the first and currently only
>>>>>>>> one there.
>>>>>>>>
>>>>>>>> The variable name could be KEPT_BODY.
>>>>>>>>
>>>>>>>> WDYT? I can also do the little reorg, but which way do we prefer?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Rainer
>>
>
