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
>
