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/06/08 20:03:31 UTC
[mp2] map to storage handler
I'm trying to work on the map to storage example. Here is what we have now:
1) From httpd-2.0/CHANGES:
*) Introduce the map_to_storage hook, which allows modules to bypass
the directory_walk and file_walk for non-file requests. TRACE
shortcut moved to http_protocol.c as APR_HOOK_MIDDLE, and the
directory_walk/file_walk happen as APR_HOOK_VERY_LAST in core.c.
[William Rowe]
s/APR_HOOK_VERY_LAST/APR_HOOK_REALLY_LAST/ in that comment.
2) And mod_perl hooks in as:
int modperl_map_to_storage_handler(request_rec *r)
{
return modperl_callback_per_srv(MP_MAP_TO_STORAGE_HANDLER, r,
MP_HOOK_RUN_FIRST);
}
3) and there is ap_send_http_trace in http_protocol.c, registered as:
ap_hook_map_to_storage(ap_send_http_trace,NULL,NULL,APR_HOOK_MIDDLE);
So we have a problem here. If one uses PerlMapToStorageHandler to shortcut the
uri2file translation, and returns OK, TRACE calls will be not handled at all.
since at the moment mod_perl runs its handler before ap_send_http_trace had a
chance to run.
Of course one could start their PerlMapToStorageHandler with:
if ($r->method_number != Apache::M_TRACE) {
return Apache::DECLINED;
}
as a workaround, but this sounds ugly. May be registering that hook on the
mod_perl side as APR_HOOK_LAST is a better idea? But how can we be sure that
tomorrow Apache won't have some other callback in the middle that we may not
want to run?
--
__________________________________________________________________
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] map to storage handler
Posted by Stas Bekman <st...@stason.org>.
Please take a look at the docs and examples I've added for maptostorage:
http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlMapToStorageHandler
Let me know if you see any problems.
I also tweaked the description of
http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlTransHandler
not to suggest doing the URI to filename translation in it.
--
__________________________________________________________________
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] map to storage handler
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>that's right - if you are implementing a PerlMapToStorageHandler then you
>>are in charge of handling all the logic that is required of core if you
>>return OK. this is exactly the same as it used to be with the
>>PerlTransHandler - return OK and you better be sure that you set
>>$r->filename to the real file or else things wont work as expected.
>
>
> ok, this still holds true.
Do you remember how TRACE was implemented in apache 1.3? I don't remember
anybody coming up with the issue of TRACE not working when using a custom
transhandler.
>>you can't do that - HOOK_RUN_FIRST means that httpd core would always return
>>OK and prevent the mod_perl callback from running.
>
>
> but this is only partially true - core_map_to_storage runs REALLY_LAST
> (sorry for not checking first). so maybe we can run PerlMapToStorage LAST. ..
You didn't need to check, I wrote that in my original email :)
> the only problem with that, though, is that if you want to implement your
> own protocol via the mod_perl API core will be handling TRACE requests even
> though they may not be part of your protocol. normally add-on modules
> (which is essentially Perl handlers in userspace) would run FIRST to
> override core behaviors, such as the HTTP specific ones.
Yes, but then you have to deal with things like TRACE. Purhaps it's simpler
not to touch MapToStorage but set a fake filename in transhandler, in which
case TRACE will work just fine.
> boy, I wish I had the time to work on that dynamic hook ordering thing again
> - it would be the perfect solution here.
Well, we could handle that later when you do have time. I just wanted to have
a complete picture so that I can document that phase with examples.
--
__________________________________________________________________
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] map to storage handler
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> that's right - if you are implementing a PerlMapToStorageHandler then you
> are in charge of handling all the logic that is required of core if you
> return OK. this is exactly the same as it used to be with the
> PerlTransHandler - return OK and you better be sure that you set
> $r->filename to the real file or else things wont work as expected.
ok, this still holds true.
> you can't do that - HOOK_RUN_FIRST means that httpd core would always return
> OK and prevent the mod_perl callback from running.
but this is only partially true - core_map_to_storage runs REALLY_LAST
(sorry for not checking first). so maybe we can run PerlMapToStorage LAST. ..
the only problem with that, though, is that if you want to implement your
own protocol via the mod_perl API core will be handling TRACE requests even
though they may not be part of your protocol. normally add-on modules
(which is essentially Perl handlers in userspace) would run FIRST to
override core behaviors, such as the HTTP specific ones.
boy, I wish I had the time to work on that dynamic hook ordering thing again
- it would be the perfect solution here.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] map to storage handler
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 3) and there is ap_send_http_trace in http_protocol.c, registered as:
> ap_hook_map_to_storage(ap_send_http_trace,NULL,NULL,APR_HOOK_MIDDLE);
>
>
>
> So we have a problem here. If one uses PerlMapToStorageHandler to
> shortcut the uri2file translation, and returns OK, TRACE calls will be
> not handled at all. since at the moment mod_perl runs its handler before
> ap_send_http_trace had a chance to run.
that's right - if you are implementing a PerlMapToStorageHandler then you
are in charge of handling all the logic that is required of core if you
return OK. this is exactly the same as it used to be with the
PerlTransHandler - return OK and you better be sure that you set
$r->filename to the real file or else things wont work as expected.
>
> Of course one could start their PerlMapToStorageHandler with:
>
> if ($r->method_number != Apache::M_TRACE) {
> return Apache::DECLINED;
> }
>
> as a workaround, but this sounds ugly.
but required if you want to handle TRACE requests (which are even more rare
than HEAD :) for an example of overriding core map_to_storage see mod_proxy.
> May be registering that hook on
> the mod_perl side as APR_HOOK_LAST is a better idea? But how can we be
> sure that tomorrow Apache won't have some other callback in the middle
> that we may not want to run?
you can't do that - HOOK_RUN_FIRST means that httpd core would always return
OK and prevent the mod_perl callback from running.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org