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
