It would *REALLY* be nice if ap_expr was r->kept_body aware. 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 <j...@jagunet.com> wrote: > >> >> On Jan 20, 2016, at 7:59 AM, Jim Jagielski <j...@jagunet.com> wrote: >> >>> >>> On Jan 20, 2016, at 3:34 AM, Rainer Jung <rainer.j...@kippdata.de> 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.
