You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2004/09/09 03:02:10 UTC
[mp2] introducing PerlOptions +GlobalServer
I'm trying to fix the logging functions in the vhost environment. In the
mp1 all the methods/functions called on anything but $r/$s was relying on
Apache->request. In mp2 Apache->request will be unavailable outside of the
httpd protocol. So in order to be able to redirect warnings to the vhost's
private log file one needs to figure out what $s should be used. Therefore
I think we need to introduce 'PerlOptions +GlobalServer', a big brother
for 'PerlOptions +GlobalRequest', which will be set in
modperl_hook_pre_connection.
When 'PerlOptions +GlobalServer' is set Apache->server can now be the
vhost/base server. Otherwise it will be the base server.
The base server will be always Apache->server->base_server or may be there
should be a direct alias Apache->base_server, which will always give us
the base server.
When implemented places where Apache->request was used only to get the
global server object, can query Apache->server.
Thoughts?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] introducing PerlOptions +GlobalServer
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Stas Bekman wrote:
> Geoffrey Young wrote:
>
>>
>> Philippe M. Chiasson wrote:
>>
>>>
>>> Stas Bekman wrote:
>>>
>>>
>>>> I'm trying to fix the logging functions in the vhost environment. In
>>>> the mp1 all the methods/functions called on anything but $r/$s was
>>>> relying on Apache->request. In mp2 Apache->request will be unavailable
>>>> outside of the httpd protocol. So in order to be able to redirect
>>>> warnings to the vhost's private log file one needs to figure out what
>>>> $s should be used. Therefore I think we need to introduce 'PerlOptions
>>>> +GlobalServer', a big brother for 'PerlOptions +GlobalRequest', which
>>>> will be set in modperl_hook_pre_connection.
>>>
>>
>>
>> this is striking me as a bit odd at the moment.
>>
>> if you're not using http then you have implemented a connection filter,
>> right? if so, then I have some thoughts.
>>
>> the entire concept of virtual host is really http based.
>
No it's not, NameVirtualHosts are. You can have virtual hosts that are only
based on a IP:Port combination.
>> that is, the only
>> way Apache currently dispatches to a vhost is by comparing the
>> request line
>> or host header to something like ServerAlias. and both the request
>> line and
>> host header are http-specific. so what exactly does it mean for a
>> non-http
>> protocol to have access to a vhost? wouldn't they need to decide for
>> themselves the mechanism by which they are sent to a virtual server,
>> which
>> by definition of not being http would mean that the decision made by
>> vhost.c:check_hostalias and whatnot would be wrong?
>>
>> the second thought is exactly what you would want to log to a
>> vhost-specific
>> log from a connection handler, since by definition they need to process
>> everything non-request-cycle related themselves. that is, where
>> would this
>> warning occur that it would need to be redirected, not have access to
>> $r,
>> but have had a http-based vhost container (properly) applied?
>
>
> It's rather simple. If you run other protocols you normally run each
> of them in a different vhost, since you need a different port. If you
> application emits warnings they will go to the main error_log. I'm
> talking about internal warnings, like compile time and calls to
> warn(). I'm not talking about explicit calls to $s->log_foo. An
> equivalent of the +GlobalRequest will allow to rewire $SIG{__WARN__}
> to log things into the vhost's error_log. At the moment this is not
> possible to accomplish.
>
Re: [mp2] introducing PerlOptions +GlobalServer
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
> Philippe M. Chiasson wrote:
>
>>
>>Stas Bekman wrote:
>>
>>
>>>I'm trying to fix the logging functions in the vhost environment. In
>>>the mp1 all the methods/functions called on anything but $r/$s was
>>>relying on Apache->request. In mp2 Apache->request will be unavailable
>>>outside of the httpd protocol. So in order to be able to redirect
>>>warnings to the vhost's private log file one needs to figure out what
>>>$s should be used. Therefore I think we need to introduce 'PerlOptions
>>>+GlobalServer', a big brother for 'PerlOptions +GlobalRequest', which
>>>will be set in modperl_hook_pre_connection.
>
>
> this is striking me as a bit odd at the moment.
>
> if you're not using http then you have implemented a connection filter,
> right? if so, then I have some thoughts.
>
> the entire concept of virtual host is really http based. that is, the only
> way Apache currently dispatches to a vhost is by comparing the request line
> or host header to something like ServerAlias. and both the request line and
> host header are http-specific. so what exactly does it mean for a non-http
> protocol to have access to a vhost? wouldn't they need to decide for
> themselves the mechanism by which they are sent to a virtual server, which
> by definition of not being http would mean that the decision made by
> vhost.c:check_hostalias and whatnot would be wrong?
>
> the second thought is exactly what you would want to log to a vhost-specific
> log from a connection handler, since by definition they need to process
> everything non-request-cycle related themselves. that is, where would this
> warning occur that it would need to be redirected, not have access to $r,
> but have had a http-based vhost container (properly) applied?
It's rather simple. If you run other protocols you normally run each of
them in a different vhost, since you need a different port. If you
application emits warnings they will go to the main error_log. I'm talking
about internal warnings, like compile time and calls to warn(). I'm not
talking about explicit calls to $s->log_foo. An equivalent of the
+GlobalRequest will allow to rewire $SIG{__WARN__} to log things into the
vhost's error_log. At the moment this is not possible to accomplish.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] introducing PerlOptions +GlobalServer
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Philippe M. Chiasson wrote:
>
>
> Stas Bekman wrote:
>
>> I'm trying to fix the logging functions in the vhost environment. In
>> the mp1 all the methods/functions called on anything but $r/$s was
>> relying on Apache->request. In mp2 Apache->request will be unavailable
>> outside of the httpd protocol. So in order to be able to redirect
>> warnings to the vhost's private log file one needs to figure out what
>> $s should be used. Therefore I think we need to introduce 'PerlOptions
>> +GlobalServer', a big brother for 'PerlOptions +GlobalRequest', which
>> will be set in modperl_hook_pre_connection.
this is striking me as a bit odd at the moment.
if you're not using http then you have implemented a connection filter,
right? if so, then I have some thoughts.
the entire concept of virtual host is really http based. that is, the only
way Apache currently dispatches to a vhost is by comparing the request line
or host header to something like ServerAlias. and both the request line and
host header are http-specific. so what exactly does it mean for a non-http
protocol to have access to a vhost? wouldn't they need to decide for
themselves the mechanism by which they are sent to a virtual server, which
by definition of not being http would mean that the decision made by
vhost.c:check_hostalias and whatnot would be wrong?
the second thought is exactly what you would want to log to a vhost-specific
log from a connection handler, since by definition they need to process
everything non-request-cycle related themselves. that is, where would this
warning occur that it would need to be redirected, not have access to $r,
but have had a http-based vhost container (properly) applied?
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] introducing PerlOptions +GlobalServer
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Stas Bekman wrote:
> I'm trying to fix the logging functions in the vhost environment. In the
> mp1 all the methods/functions called on anything but $r/$s was relying on
> Apache->request. In mp2 Apache->request will be unavailable outside of the
> httpd protocol. So in order to be able to redirect warnings to the vhost's
> private log file one needs to figure out what $s should be used. Therefore
> I think we need to introduce 'PerlOptions +GlobalServer', a big brother
> for 'PerlOptions +GlobalRequest', which will be set in
> modperl_hook_pre_connection.
>
> When 'PerlOptions +GlobalServer' is set Apache->server can now be the
> vhost/base server. Otherwise it will be the base server.
>
> The base server will be always Apache->server->base_server or may be there
> should be a direct alias Apache->base_server, which will always give us
> the base server.
>
> When implemented places where Apache->request was used only to get the
> global server object, can query Apache->server.
>
> Thoughts?
Sounds like both a good idea and a necessary one.
--
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5