Ugg... it seems that updating ap_expr results in bison stepping in and redoing stuff... Thing is, I have Bison 3.0.4 and the old files seems to have been based on 2.7:
diff --git a/server/util_expr_parse.c b/server/util_expr_parse.c index d5891c6..b9ad317 100644 --- a/server/util_expr_parse.c +++ b/server/util_expr_parse.c @@ -1,19 +1,19 @@ -/* A Bison parser, made by GNU Bison 2.7.12-4996. */ +/* A Bison parser, made by GNU Bison 3.0.4. */ /* Bison implementation for Yacc-like parsers in C - - Copyright (C) 1984, 1989-1990, 2000-2013 Free Software Foundation, Inc. - + + Copyright (C) 1984, 1989-1990, 2000-2015 Free Software Foundation, Inc. + > On Jan 20, 2016, at 11:31 AM, Jim Jagielski <[email protected]> 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 <[email protected]> wrote: >> >> Am 20.01.2016 um 16:28 schrieb Jim Jagielski: >>> >>>> On Jan 20, 2016, at 9:57 AM, Jim Jagielski <[email protected]> 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 <[email protected]> wrote: >>>>> >>>>>> >>>>>> On Jan 20, 2016, at 7:59 AM, Jim Jagielski <[email protected]> wrote: >>>>>> >>>>>>> >>>>>>> On Jan 20, 2016, at 3:34 AM, Rainer Jung <[email protected]> >>>>>>> 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. >
