RE: AddHandler scope
I've been working on a module and quite unexpectedly I found that my AddHandler directive was taking affect at a global level even though it was defined within a virtual host block. So it was affecting Apache manual pages that weren't in the virtual host for which I had created the AddHandler directive. Am I misunderstanding the scope of AddHandler? I am using named virtual host. For testing I have all of the named hosts defined in my HOSTS file to point to 127.0.0.1. So in a sense it all goes to the same place. I wouldn't have thought that would have made a difference. Hmm, considering AddHandler is implemented by mod_mime, I would find it very suspicious that this is behaving this way. Can you please post a configuration snippet that demonstrates this behavior? -- justin OK, I think I got it down to the bare minimum. The attached files live in C:\Apache2\foobar on my Windows 2000 system. I run Apache 2.0.46. The attached httpd.conf is intended to be Included at the end of the normal httpd.conf. I keep my httpd.conf (mostly) 'stock' so there shouldn't be any real issues there. My HOSTS file defines: 127.0.0.1 localhost 127.0.0.1 Scope.Doorways.home which may be some or all of the issue. This is how I do testing (obviously, since I'm using a non-standard domain name). The mod_foobar.c file is a trivial module that just prints the handler name and filename and DECLINEs. I've included a Makefile that works with my version of Microsoft's C compiler, which is whatever comes with Visual Studio 6. When I run Apache and hit it with: http://localhost/manual my error log contains: [Mon Jun 30 13:23:35 2003] [info] [client 127.0.0.1] foobar_handler(foobar, localhost, C:/Apache2/manual/index.html.en) [Mon Jun 30 13:23:35 2003] [info] [client 127.0.0.1] foobar_handler(text/css, localhost, C:/Apache2/manual/style/css/manual.css), referer: http://localhost/manual/ [Mon Jun 30 13:23:35 2003] [info] [client 127.0.0.1] foobar_handler(text/css, localhost, C:/Apache2/manual/style/css/manual-print.css), referer: http://localhost/manual/ [Mon Jun 30 13:23:35 2003] [info] [client 127.0.0.1] foobar_handler(image/gif, localhost, C:/Apache2/manual/images/left.gif), referer: http://localhost/manual/ [Mon Jun 30 13:23:35 2003] [info] [client 127.0.0.1] foobar_handler(image/gif, localhost, C:/Apache2/manual/images/feather.gif), referer: http://localhost/manual/ [Mon Jun 30 13:23:35 2003] [info] [client 127.0.0.1] foobar_handler(text/css, localhost, C:/Apache2/manual/style/css/manual-loose-100pc.css), referer: http://localhost/manual/ Hitting it with: http://Scope.Doorways.home gives me the appropriate index file (also supplied but irrelevant) and my error log contains: [Mon Jun 30 13:24:00 2003] [info] [client 127.0.0.1] foobar_handler(foobar, scope.doorways.home, C:/Apache2/foobar/index.html) So the module is being invoked for the Apache manual pages even though they are not defined in the virtual server block in which I added the handler. This is what confuses me. I wouldn't think that this would happen. I keep thinking that perhaps the fact that both domain names resolve to 127.0.0.1 via my HOSTS file could be confusing Apache. But they're named virtual servers, so I feel like that _shouldn't_ be an issue since I'm asking for different hosts via the browser. And the request record is showing different hostnames in the log. Anyway, I'm probably missing something simple in the configuration file. mma httpd.conf Description: Binary data mod_foobar.c Description: Binary data Makefile Description: Binary data Title: Some Title Some stuff
RE: ap_max_requests_per_child isn't part of the API, is it?
A FAQ Wiki might be useful. Then we could copy chunks of emails into the wiki and later reference the wiki pages by URL. This would be a temporary collecting point for the data pending formal documentation, and as such might help to organize it. mma -Original Message- From: Jeff Trawick [mailto:[EMAIL PROTECTED] Sent: Sunday, June 29, 2003 5:52 AM To: [EMAIL PROTECTED] Subject: Re: ap_max_requests_per_child isn't part of the API, is it? Bennett, Tony - CNF wrote: Jeff, You referred to formal definition of our API Is it documented somewhere? not that I know of, but I think it would be good to start writing down some conclusions to questions like this
AddHandler scope
Apache 2.0.46, W2K I've been working on a module and quite unexpectedly I found that my AddHandler directive was taking affect at a global level even though it was defined within a virtual host block. So it was affecting Apache manual pages that weren't in the virtual host for which I had created the AddHandler directive. Am I misunderstanding the scope of AddHandler? I am using named virtual host. For testing I have all of the named hosts defined in my HOSTS file to point to 127.0.0.1. So in a sense it all goes to the same place. I wouldn't have thought that would have made a difference. mma
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
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
Config blocks
Is adding 'blocks' (e.g. Perl.../Perl) in configuration files encouraged or discouraged? I've been considering one such in a module of mine, and looking at example code in mod_macro and mod_perl that does this type of thing. The code to add a block isn't nearly as clean as code to add a single-line directive. I was thinking that perhaps adding blocks was discouraged (perhaps because of apps like webgui). Or perhaps it is just rare enough that it hasn't been codified in the API yet. mma
RE: Config blocks
Encouraged, although if we do overhaul the parser from two to three passes you might have a bit of porting work, and your module probably won't remain compatible with most apache 'configurators'. So it goes. If you are doing your own thing, look at macro or perl modules. If you are implementing a scoped apache block, look at mod_proxy instead, which processes proxy 'location' directives. It's a good example of adding new Apache directive contexts. The mod_macro and mod_perl code both seem to read from the configuration file via ap_cfg_getline until they find the terminating tag for the block. I'm unable to find a corresponding loop in mod_proxy. It looks, instead, as if ap_walk_config is used instead. Does this mean that at the time of the call to process the open tag of the block the configuration file has already been processed into a tree structure? 'Cause that certainly makes life a _lot_ easier. mma
merge_dir_config calls
Apache 2.0.46, W2K, working on a module... I'm tracing calls to the module's dir/svr create/merge calls (the ones specified in the module data object along with a pointer to the command array and the hook register function). I'm not clear on when Apache should be calling the merge functions. If I have in httpd.conf: Location /TEMP directive alpha /Location Location /alpha/xfer directive bravo /Location or Directory C:/TEMP directive alpha /Directory Directory C:/TEMP/xfer directive bravo /Directory should I be getting calls to merge the two directories in one or both of these examples? Currently the only dir merge call I get is from one unnamed directory to another. I do, however, get appropriate server and directory creation calls and calls to command handlers for directives I have defined in these directories. Hopefully the following trace will clarify more than obfuscate (I trace the directory or server hostnames on the create calls, then copy them into the allocated config areas so I can trace them again on the merge calls): [T] gate_register_hook [T] gate_cfg_svr_create((null)) [T] gate_cfg_dir_create((null)) [T] gate_cfg_dir_create(/TEMP) [T] gate_cmd_syntax(alpha) [T] gate_cfg_dir_create(/TEMP/xfer) [T] gate_cmd_syntax(bravo) [T] gate_cfg_dir_create((null)) [T] gate_cfg_svr_create(GATE.Doorways.home) [T] gate_cmd_baseDir(C:\GATE/doc/htdocs) [T] gate_cmd_syntax(macro) [T] gate_cfg_dir_create(/tools) [T] gate_cmd_syntax(backrub) [T] gate_cfg_dir_create(/tools/info) [T] gate_cmd_syntax(mofo) [T] gate_cfg_dir_create(/tools/info) [T] gate_cmd_baseDir(C:\GATE/doc/htdocs) [T] gate_cfg_dir_create(C:/TEMP/) [T] gate_cmd_baseDir(C:\GATE/doc/htdocs) [T] gate_cfg_dir_create(C:/TEMP/xfer/) [T] gate_cmd_baseDir(C:\GATE/doc/htdocs) [T] gate_cfg_svr_merge((null), GATE.Doorways.home) [T] gate_cfg_dir_merge((null), (null)) And that's it. Numerous directories created both inside of and outside of virtual server blocks. A single server merge call that looks as I expect and a single directory merge call that leaves me perplexed. I'm probably misunderstanding how these calls are supposed to be used...any clarification would be helpful. thx mma [T] gate_register_hook [T] gate_cfg_svr_create(23a698, (null)) [T] gate_cfg_dir_create(23a698, (null)) [T] gate_cfg_dir_create(23a698, /TEMP) [T] gate_cmd_syntax(alpha) [T] gate_cmd_acquire_engine(23a698, 77f4c8) [T] engine: 0 [T] engine: 77f4d8 [T] gate_cfg_dir_create(23a698, /TEMP/xfer) [T] gate_cmd_syntax(bravo) [T] gate_cmd_acquire_engine(23a698, 77f710) [T] engine: 0 [T] engine: 77f720 [T] gate_cfg_dir_create(23a698, (null)) [T] gate_cfg_svr_create(23a698, GATE.Doorways.home) [T] gate_cmd_baseDir(C:\GATE/doc/htdocs) [T] gate_cmd_acquire_engine(23a698, 780378) [T] engine: 0 [T] engine: 7803a0 [T] gate_cmd_syntax(macro) [T] gate_cmd_acquire_engine(23a698, 780378) [T] engine: 7803a0 [T] gate_cfg_dir_create(23a698, /tools) [T] gate_cmd_syntax(backrub) [T] gate_cmd_acquire_engine(23a698, 780638) [T] engine: 0 [T] engine: 780650 [T] gate_cfg_dir_create(23a698, /tools/info) [T] gate_cmd_syntax(mofo) [T] gate_cmd_acquire_engine(23a698, 77e4e8) [T] engine: 0 [T] engine: 77e4f8 [T] gate_cfg_dir_create(23a698, /tools/info) [T] gate_cmd_baseDir(C:\GATE/doc/htdocs) [T] gate_cmd_acquire_engine(23a698, 7809e0) [T] engine: 0 [T] engine: 780a00 [T] gate_cfg_dir_create(23a698, C:/TEMP/) [T] gate_cmd_baseDir(C:\GATE/doc/htdocs) [T] gate_cmd_acquire_engine(23a698, 780c60) [T] engine: 0 [T] engine: 780c80 [T] gate_cfg_dir_create(23a698, C:/TEMP/xfer/) [T] gate_cmd_baseDir(C:\GATE/doc/htdocs) [T] gate_cmd_acquire_engine(23a698, 780ee8) [T] engine: 0 [T] engine: 780f08 [T] gate_cfg_svr_merge(23a698, (null):0, GATE.Doorways.home:0) [T] gate_cfg_dir_merge(23a698, (null):0, (null):7803a0)
RE: merge_dir_config calls
Sorry...I intended to put this on 'modules'...which I have now done...mea culpa -Original Message- From: Marc M. Adkins [mailto:[EMAIL PROTECTED] Sent: Monday, June 09, 2003 12:21 PM To: [EMAIL PROTECTED] Subject: merge_dir_config calls
