httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: Work in progress: mod_proxy Health Check module
Date Wed, 20 Jan 2016 16:11:20 GMT
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