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: <569FB1A8.9080208@kippdata.de>
Date: Wed, 20 Jan 2016 11:31:11 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <2E486C0B-230B-48D2-8A91-07FF37E876DC@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>
 <F14DA3A0-E5E6-4687-9D96-38669354A276@jaguNET.com>
 <569FB1A8.9080208@kippdata.de>
To: dev@httpd.apache.org

=46rom 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);
 }
=20
+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 =3D apr_brigade_length(ctx->r->kept_body, 1, &length);
+    if (rv !=3D APR_SUCCESS || length =3D=3D 0)
+        return "";
+
+    buf =3D 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[] =3D {
     { 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 <rainer.jung@kippdata.de> =
wrote:
>=20
> Am 20.01.2016 um 16:28 schrieb Jim Jagielski:
>>=20
>>> 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
>>=20
>> Actually, that does NOT look that difficult...
>>=20
>> Comments? Should I go for it?
>=20
> 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).
>=20
> Regards,
>=20
> Rainer
>=20
>>> 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.