Stas Bekman wrote: > It looks like besides testing the API we also may want to test some > common techniques. e.g. for one of the recent problem reports on the > modperl list, I wrote this rewrite test. Should I commit it? If so, > should we start a new category of tests for common techniques. Not sure > what's the best short name, 'cooks', 'recetas' or 'fill in some short > name'?
what about just 'user'? > > BTW, Apache now requires you to set $r->filename() if you return > Apache::OK from the transhandler. well, that's true but I think your comment is a bit misleading. returning OK from a trans handler _means_ that you have set r->filename. in other words, Apache is both expecting and enforcing that r->filename be set by the end of translation. but wait, there's more... > In this test I simply left for Apache > to figure it out, but obviously we get the stat() calls perfomance hit. the old reason that we used to return OK from a trans handler was to avoid the stat for non-file URIs. however, this stat now happens in map-to-storage, not translation. hence it is core_map_to_storage that throws the "module bug?" warning. well, ok, it's ap_directory_walk, but now that is only called from core_map_to_storage (and a few other modules like proxy and dav). so, what this means is that if you want to avoid the stat call you need to return OK from a PerlMapToStorageHandler, not the PerlTransHandler. also, in these cases you can skip the PerlTransHandler altogether - there is no benefit whatsoever from returning OK from perl except that it might actually slow you down, depending on how fast the perl is compared to ap_core_translate. good thing we have a PerlMapToStorageHandler ;) HTH --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
