On Wed, Aug 18, 2004 at 12:27:02PM -0700, Stas Bekman wrote: > Glenn Strauss wrote: > >On Wed, Aug 18, 2004 at 10:59:25AM -0700, Stas Bekman wrote: > > > >>Glenn Strauss wrote: > >> > >>>Apache caches the server_rec, so as Stas said, modifying it affects > >>>things globally, and across the request. In C, if I wanted to > >>>local'ize the server_rec for the request, I would make a copy of the > >>>server_rec, store it in r->server, and then modify its contents > >>>(top-level only) through r->server. > >>> > >>>Stas: is there a way to do this in mod_perl? What do you think of > >>>local'izing the server_rec when an application attempts to make > >>>request-specific changes? There would need to be a clear API for > >>>making request-specific or global changes. (Changes through > >>>r->server instead of directly through the global server rec, > >>>e.g. in the main httpd.conf) Maybe pass $r as an arg to the > >>>server_rec method if you want it local'ized? Just musing ... > >> > >>Hmm, how do you see that idea working, Glenn? even if we could localize > >>server_rec, the rest of the Apache will still see the un-localized one, > >>so we don't achieve much. If you wanted to change things just for the > >>mod_perl handlers scope, just stick a new docroot in some singleton and > >>use that in your code. > > > > > >I'm talking about copying the entire server_rec of r->server wholesale > >and placing a copy in r->server and then modifying the copy. > >(I'm talking at the C level, here.) Any filters that reference r > >would see the new copy in r->server. > > how do you make sure that Apache components and modules don't have their > own reference of server stashed somewhere and accessing it not via > r->server? > > >All of this is theoretical, mind you. > > Yes, yes, I understand :) > > in the particular case of document_root it doesn't live in the server_rec > structure. It lives in the core_module's structure: > > conf = (core_server_config > *)ap_get_module_config(r->server->module_config, > &core_module); > > return conf->ap_document_root; > > so localizing server_rec won't help here.
Ergh. I hadn't looked where ap_document_root was. Thanks for the correction. The same hack _might_ work; r->server would need to be copied, r->server->module_config would need to be copied, and _then_ the core module's config could be replaced with a local copy for the request. That's not to say it _should_ be done -- just that it might be possible. :) > I think this is something that Apache 2.1/2 should address. Having > server-wide config localized for requests. it'll benefit things like > mod_userdir, us and many other modules which may have the need to modify > server-wide values for the duration of the request. Agreed. (Straying a bit off-topic here) How would you approach that? Always deep-copying the entire server_rec and conn_rec for each request seems to me to be very expensive, and would either require too much internal knowledge of each module's config, or would require that all modules be rewritten to provide a hook for localizing their private configs. Neither seems likely to happen. Besides, that sounds like the solution to the wrong problem. There should be a better way to get information like document_root or userdir information without reaching into private module configs. If we're talking "filesystem mappings" then there ought to be a way for all modules that deal with "filesystem mapping" to share and exchange information _and_ make sure that all other "filesystem mapping" modules have access to and _use_ these changes. The same goes for user lookups. There should be never be a time that multiple modules during the _same_ request should have to make multiple getpwnam() or LDAP or other lookups on the same userid. They should be able to share that information. If you have any suggestions how to do this under the hood in Apache, I'll make an attempt to code it. Cheers, Glenn -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
