Proxy's pre_request and post_request hooks

[Jim Jagielski <ji...@jaguNET.com>]

Right now, both of these are defined as
APR_IMPLEMENT_EXTERNAL_HOOK_RUN_FIRST and the ones we use
are at APR_HOOK_FIRST. They also always return OK (unless
an error) so this means that we can never add additional
hooks here and have them run (don't talk to me about
REALLY_FIRST :) ).

Anyway, considering some of the LB stuff we've been talking
about, it would be very useful to be able to have providers
and others utilize these hooks (eg: for timestamping start
and end of requests), but with RUN_FIRST, we're limiting
that.

Soooooo I'm proposing changing to RUN_ALL...

Comments?

Re: Proxy's pre_request and post_request hooks

[Jim Jagielski <ji...@jaguNET.com>]

On Feb 15, 2008, at 1:21 PM, Nick Kew wrote:

> On Thu, 14 Feb 2008 15:07:38 -0500
> Jim Jagielski <ji...@jaguNET.com> wrote:
>
>> Right now, both of these are defined as
>> APR_IMPLEMENT_EXTERNAL_HOOK_RUN_FIRST and the ones we use
>> are at APR_HOOK_FIRST. They also always return OK (unless
>> an error) so this means that we can never add additional
>> hooks here and have them run (don't talk to me about
>> REALLY_FIRST :) ).
>>
>> Anyway, considering some of the LB stuff we've been talking
>> about, it would be very useful to be able to have providers
>> and others utilize these hooks (eg: for timestamping start
>> and end of requests), but with RUN_FIRST, we're limiting
>> that.
>>
>> Soooooo I'm proposing changing to RUN_ALL...
>>
>> Comments?
>
> That's a public API you're proposing to change.  Ergo, something
> on a 2.4 timescale.
>

This was proposed for -trunk; but it would be useful for 2.2
as well...

> Wouldn't changing existing HOOK_FIRST functions to return DECLINED
> achieve what you need without breaking anything?

But ap_proxy_pre_request() would need adjustment... which
is also an "exported" function...

Of course, I don't see how this could impact anyone external
since the very fact that they are RUN_FIRST and HOOK_FIRST
implies no one else is (able to) use them right now...
So yes, even though would change the public API of these
2 hooks, I think the usefulness of it is worth it, and
hence why I wanted comments :)

Re: Proxy's pre_request and post_request hooks

[Nick Kew <ni...@webthing.com>]

On Thu, 14 Feb 2008 15:07:38 -0500
Jim Jagielski <ji...@jaguNET.com> wrote:

> Right now, both of these are defined as
> APR_IMPLEMENT_EXTERNAL_HOOK_RUN_FIRST and the ones we use
> are at APR_HOOK_FIRST. They also always return OK (unless
> an error) so this means that we can never add additional
> hooks here and have them run (don't talk to me about
> REALLY_FIRST :) ).
> 
> Anyway, considering some of the LB stuff we've been talking
> about, it would be very useful to be able to have providers
> and others utilize these hooks (eg: for timestamping start
> and end of requests), but with RUN_FIRST, we're limiting
> that.
> 
> Soooooo I'm proposing changing to RUN_ALL...
> 
> Comments?

That's a public API you're proposing to change.  Ergo, something
on a 2.4 timescale.

Wouldn't changing existing HOOK_FIRST functions to return DECLINED
achieve what you need without breaking anything?

-- 
Nick Kew

Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/

Re: Proxy's pre_request and post_request hooks

[Jim Jagielski <ji...@jaguNET.com>]

I'm looking at adding 2 new hooks proxy_hook_pre_shandler and
proxy_hook_post_shandler which run right before/after scheme_handler
(or after/before pre_request/post_request) to add the functionality
that the existing hooks don't... Mainly, this is so it can
live in trunk, be tested there and then proposed for 2.2
backport.

Re: Proxy's pre_request and post_request hooks

[Jim Jagielski <ji...@jaguNET.com>]

On Feb 16, 2008, at 8:55 AM, Dirk-Willem van Gulik wrote:

>
> On Feb 15, 2008, at 7:12 PM, Jim Jagielski wrote:
>
>>
>> On Feb 14, 2008, at 3:07 PM, Jim Jagielski wrote:
>>>
>>> Soooooo I'm proposing changing to RUN_ALL...
>>>
>>
>> Bueller...?  Bueller...?
>
> Just been playing a bit - but fail to understand how this can be  
> made to work for anything old ? Or am I misunderstanding your 2.2.  
> desires and is this pure trunk ?
>

As mentioned previously, this is for trunk, but not pure
trunk.

IMO, this needs to be fixed, at least in trunk. The current
impl basically prevents anything else from using these hooks,
with the assumption that once our hooks complete, no one
else would possibly want to use them. In which case, why
even have a hook? So, I am guessing that there is no one
else in the whole wide world using this "API"... We make
it too difficult for them. Unless you use REALLY_FIRST,
you are pretty much guaranteed that you won't be called.
Doesn't that seem bogus?

Alternately, of course, would be adding 2 additional
hooks after proxy_run_pre_request and another between
proxy_run_post_request and proxy_run_request_status...
But that's just ugly :)

Re: Proxy's pre_request and post_request hooks

[Dirk-Willem van Gulik <di...@webweaving.org>]

On Feb 15, 2008, at 7:12 PM, Jim Jagielski wrote:

>
> On Feb 14, 2008, at 3:07 PM, Jim Jagielski wrote:
>>
>> Soooooo I'm proposing changing to RUN_ALL...
>>
>
> Bueller...?  Bueller...?

Just been playing a bit - but fail to understand how this can be made  
to work for anything old ? Or am I misunderstanding your 2.2. desires  
and is this pure trunk ?

Dw

Re: Proxy's pre_request and post_request hooks

[Jim Jagielski <ji...@jaguNET.com>]

On Feb 14, 2008, at 3:07 PM, Jim Jagielski wrote:
>
> Soooooo I'm proposing changing to RUN_ALL...
>

Bueller...?  Bueller...?

Re: Proxy's pre_request and post_request hooks

[Graham Leggett <mi...@sharp.fm>]

Jim Jagielski wrote:

> Soooooo I'm proposing changing to RUN_ALL...
> 
> Comments?

It makes sense, the question though would be whether it could be done in 
a way that is backwards compatible.

Regards,
Graham
--