questions from my trivial patch

[Brian Degenhardt <bm...@mp3.com>]

The functions for ap_hook_open_logs, ap_hook_post_config, and
ap_hook_pre_config will fail if DECLINE is returned.  Is that
intentional?

In the quick_handler, returning HTTP_mumble will result in that status
being returned in a real request, but it will fallback to the real
handler in a subrequest.  Is that intentional?

What's the difference between adding your filters inside your
ap_hook_insert_filter hook versus calling ap_register_*_filter right
inside of the register_hooks callback?

-bmd

Re: questions from my trivial patch

[Bill Stoddard <bi...@wstoddard.com>]

>
> > In the quick_handler, returning HTTP_mumble will result in that status
> > being returned in a real request, but it will fallback to the real
> > handler in a subrequest.  Is that intentional?
>
> I don't know, but it sounds completely incorrect.  Bill, can you shed
> any light here?

The primary use of quick_handler is for a url keyed cache, so it must be able to handle
returning an HTTP_NOT_MODIFIED.  If mod_cache elects to handle the request and for some
reason the ap_pass_brigade fails (ie, quick_handler returns with something other than OK
or DECLINED) we need to handle that case as well. Conclusion... quick_handler needs be
able to throw HTTP_mumble status responses on mainline requests.

I don't think we have tested mod_cache enough with subrequests to know for certain what is
most useful. I am inclined to think that quick_handler on subrequests should always return
either OK or DECLINED.

Bill

RE: questions from my trivial patch

[Ryan Bloom <rb...@covalent.net>]

> From: Brian Degenhardt [mailto:bmd@mp3.com]
> 
> The functions for ap_hook_open_logs, ap_hook_post_config, and
> ap_hook_pre_config will fail if DECLINE is returned.  Is that
> intentional?

Yes.  This is because those are configuration phases.  If a module tries
to do something in those phases and can't, then the server should not
continue to run, because something wasn't configured properly.  If the
server did continue, then it would most likely not behave the way it was
expected to.

> In the quick_handler, returning HTTP_mumble will result in that status
> being returned in a real request, but it will fallback to the real
> handler in a subrequest.  Is that intentional?

I don't know, but it sounds completely incorrect.  Bill, can you shed
any light here?

> What's the difference between adding your filters inside your
> ap_hook_insert_filter hook versus calling ap_register_*_filter right
> inside of the register_hooks callback?

You are confusing registering and adding hooks.  You should always
register the hooks in register_hooks, but adding the hook to the request
should be done during request processing.  Basically registering a
filter lets the server know that the filter exists, but it doesn't
enable it for any requests.  Adding the filter enables it for that
request.

Ryan