Am 21.01.2016 um 19:08 schrieb Jim Jagielski:
That is with:

   ProxyHCExpr foof2 {hc('body') !~ /domain is established/}

With

   ProxyHCExpr foof2 {kept_body('body') !~ /domain is established/}

Can you provide a simple but somehow complete proxy_hcheck config snippet? I'll set up a test and check what's wrong.

Regards,

Rainer

it works as expected.

Thx!
On Jan 21, 2016, at 1:06 PM, Jim Jagielski <j...@jagunet.com> 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 <rainer.j...@kippdata.de> 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 <rainer.j...@kippdata.de> 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 <j...@jagunet.com> wrote:

Sounds good to me!!

thx!

On Jan 21, 2016, at 10:23 AM, Rainer Jung <rainer.j...@kippdata.de> 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

Reply via email to