Re: response handlers get all requests
[EMAIL PROTECTED] wrote: Marc M. Adkins wrote: The ap_hook_handler() call does not specify the handler key from the corresponding AddHandler configuration directive. As a consequence, the specified handler function must look at and accept or decline each request. yes, you are right. IMO that sucks, for a number of reasons: * the Apache 1.3 core was better about it and only called handlers when the request type matched a type the handler was interested in, * we had to change the module API to accomodate this regression in the core, and * now we have a distributed performance hit in 2.x, because the core is calling all these modules who don't care about the request which makes the CPU fetch crap instructions into the i-cache. This won't show up as a hot spot in a profiler, because it is spread among all the different handlers and other code which is now taking more frequent i-cache misses. ...but I'll shut up because I don't have a patch or a design for one yet. By contrast, output filters only see requests in which they have interest. Clearly a better situation. The change in handlers was made for a reason. The problem is, I've forgotten the reason! A survey of all the existing handlers might well reveal it - otoh, the reason might simply be that filtering hooks didn't fit neatly with the new hook API. Which is, of course, fixable, at the cost of some complication. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff
RE: response handlers get all requests
... The ap_hook_handler() call does not specify the handler key from the corresponding AddHandler configuration directive. As a consequence, the specified handler function must look at and accept or decline each request I'm looking at trace statements and my handler must reject PNG files and so forth... your handler needs to look at r-handler and decline stuff that you're not supposed to handle Yeah, that's what I'm doing. It just seems odd that this step is necessary with response handlers but not with filters. It also seems inefficient, as now each handler in a particular directory is calling strcmp() against r-handler for a lot of files that don't apply (albeit there will only be a few handlers registered for any given directory). So my handler has to reject PNG files and so forth, which are obviously not matches as specified by directivies in httpd.conf. Seems like whatever mechanism is in place for filters could be used for response handlers. Symmetry, neh? But there's probably some rationale for this that hasn't surfaced yet. Some particular usage case that wouldn't be properly supported any other way. mma
Re: response handlers get all requests
Marc M. Adkins wrote: The ap_hook_handler() call does not specify the handler key from the corresponding AddHandler configuration directive. As a consequence, the specified handler function must look at and accept or decline each request. yes, you are right. IMO that sucks, for a number of reasons: * the Apache 1.3 core was better about it and only called handlers when the request type matched a type the handler was interested in, * we had to change the module API to accomodate this regression in the core, and * now we have a distributed performance hit in 2.x, because the core is calling all these modules who don't care about the request which makes the CPU fetch crap instructions into the i-cache. This won't show up as a hot spot in a profiler, because it is spread among all the different handlers and other code which is now taking more frequent i-cache misses. ...but I'll shut up because I don't have a patch or a design for one yet. By contrast, output filters only see requests in which they have interest. Clearly a better situation. Greg
Re: response handlers get all requests
Marc M. Adkins wrote: ... The ap_hook_handler() call does not specify the handler key from the corresponding AddHandler configuration directive. As a consequence, the specified handler function must look at and accept or decline each request yep, see most handlers in the modules provided with Apache (mod_autoindex, mod_cgi, etc.) Is there a rationale for this? dunno Am I missing a register_hook function that would allow me to set a key for a response handler? no I'm looking at trace statements and my handler must reject PNG files and so forth... your handler needs to look at r-handler and decline stuff that you're not supposed to handle
response handlers get all requests
The syntax for ap_register_output_filter() specifies the handler 'key' used in the AddOutputFilter configuration directive. The ap_hook_handler() call does not specify the handler key from the corresponding AddHandler configuration directive. As a consequence, the specified handler function must look at and accept or decline each request. By contrast, output filters only see requests in which they have interest. Is there a rationale for this? Am I missing a register_hook function that would allow me to set a key for a response handler? I'm looking at trace statements and my handler must reject PNG files and so forth...seems like this is less efficient than it could be. I'm probably missing something. mma
