> On Jan 20, 2016, at 9:57 AM, Jim Jagielski <j...@jagunet.com> 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? > 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. >
