httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: Work in progress: mod_proxy Health Check module
Date Wed, 20 Jan 2016 16:31:11 GMT
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 <rainer.jung@kippdata.de> wrote:
> 
> Am 20.01.2016 um 16:28 schrieb Jim Jagielski:
>> 
>>> On Jan 20, 2016, at 9:57 AM, Jim Jagielski <jim@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?
> 
> 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 <jim@jaguNET.com> wrote:
>>>> 
>>>>> 
>>>>> On Jan 20, 2016, at 7:59 AM, Jim Jagielski <jim@jaguNET.com> wrote:
>>>>> 
>>>>>> 
>>>>>> On Jan 20, 2016, at 3:34 AM, Rainer Jung <rainer.jung@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.


Mime
View raw message