Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Subject: Re: Work in progress: mod_proxy Health Check module
From: Jim Jagielski <jim@jaguNET.com>
In-Reply-To: <F5D5F1DE-0882-4A2D-92BD-FE5893AEAAE5@jaguNET.com>
Date: Wed, 20 Jan 2016 10:28:32 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <F14DA3A0-E5E6-4687-9D96-38669354A276@jaguNET.com>
References: <F3D7A615-23EF-4809-9BC3-9E1CA44212A5@jaguNET.com>
 <25B13108-E732-422F-B3C2-41B5E0EB22D1@jaguNET.com>
 <9EE59597-7931-484A-A61E-1A4715D9F5A3@c8h10n4o2.org.uk>
 <41F5D009-7C4E-47AB-8FE7-0B0C97E569FA@jaguNET.com>
 <569F4683.8020206@kippdata.de>
 <23C0818C-160A-4907-B574-B8853CF582A1@jaguNET.com>
 <91142A15-43F3-4AE2-8227-8866EA5F9DE4@jaguNET.com>
 <F5D5F1DE-0882-4A2D-92BD-FE5893AEAAE5@jaguNET.com>
To: dev@httpd.apache.org


> On Jan 20, 2016, at 9:57 AM, Jim Jagielski <jim@jaguNET.com> wrote:
>=20
> It would *REALLY* be nice if ap_expr was r->kept_body
> aware.
>=20

Actually, that does NOT look that difficult...=20

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 :)
>=20
>> On Jan 20, 2016, at 8:08 AM, Jim Jagielski <jim@jaguNET.com> wrote:
>>=20
>>>=20
>>> On Jan 20, 2016, at 7:59 AM, Jim Jagielski <jim@jaguNET.com> wrote:
>>>=20
>>>>=20
>>>> On Jan 20, 2016, at 3:34 AM, Rainer Jung <rainer.jung@kippdata.de> =
wrote:
>>>>=20
>>>> 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.
>>>>>=20
>>>>> 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.
>>>>=20
>>>> 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.
>>>>=20
>>>=20
>>> 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.
>>=20
>> I guess I could shove the response body in the request note
>> array... let me see.
>=20