It seems that for $r->finfo we can't provide a familar get/set idiom of
returning the previous value when the new value is set:
$r->finfo($finfo);
Normally we try to return the previous value, but in this case in C land:
r->finfo is the struct itself, not a pointer to it. So $r->finfo($finfo)
On May 24, 2004, at 5:35 PM, Stas Bekman wrote:
That's not quite click-able, isn't it? :)
Stupid Wiki + Mail client. It's the last question here:
http://www.masonhq.com/?FAQ:ServerConfiguration
Regards,
David
-
To unsubscribe, e-
David Wheeler wrote:
On May 24, 2004, at 5:26 PM, Geoffrey Young wrote:
yeah, that looks and sounds right. cool.
Whew! Added to the Mason FAQ:
http://www.masonhq.com/?FAQ:ServerConfiguration#h-
i_m_using_html__mason___apachehandler_and_i_have___decline_dirs__disable
d_and_am_using_a_dhandler
On May 24, 2004, at 5:26 PM, Geoffrey Young wrote:
yeah, that looks and sounds right. cool.
Whew! Added to the Mason FAQ:
http://www.masonhq.com/?FAQ:ServerConfiguration#h-
i_m_using_html__mason___apachehandler_and_i_have___decline_dirs__disable
d_and_am_using_a_dhandler_to_handle_directory_
David Wheeler wrote:
> On May 24, 2004, at 5:17 PM, Geoffrey Young wrote:
>
>> ok, that still looks funky. here's where I'm coming from, which may be
>> different than where you're coming from :)
>
>
> Heh, okay, sorry for my density. ;-)_
no problem. I'm the dense one most of the time :)
On May 24, 2004, at 5:17 PM, Geoffrey Young wrote:
ok, that still looks funky. here's where I'm coming from, which may be
different than where you're coming from :)
Heh, okay, sorry for my density. ;-)_
mod_perl is typically set up to handle stuff correctly. the problem
exists
where mod_perl is
>> I think that 'unless' should be 'if' - if the request is for a directory,
>> and if the directory has a trailing slash, set the content handler to be
>> perl-script. I think the above logic demorgans out to
>>
>> if ( ! $r->content_type eq DIR_MAGIC_TYPE || $uri !~ m{/$} )
>>
>> which isn't
On May 24, 2004, at 12:55 PM, Geoffrey Young wrote:
<%init>;
use Apache::Constants qw(DIR_MAGIC_TYPE);
$m->abort(-1) if $r->content_type eq DIR_MAGIC_TYPE && $r->uri !~
m{/$};
-1 is DECLINED, right?
For Mason it is, at any rate. If it's the same as DECLINED, I'll use
that, instead.
sub
Joe Orton wrote:
On the subject of duplicate symbol definitions, I ran the script I have
to check for such things against mod_perl and it found a few already,
using mod_perl 1.99_12 (httpd-2.0.49, perl 5.8.3).
mod_perl.so ModPerl/Const/Const.so => modperl_constants_group_lookup_apache
mod_perl.so
> You can add these lines to the top of your dhandler to handle the redirect
> yourself:
>
> <%init>;
> use Apache::Constants qw(DIR_MAGIC_TYPE);
> $m->abort(-1) if $r->content_type eq DIR_MAGIC_TYPE && $r->uri !~ m{/$};
>
-1 is DECLINED, right?
>
> The status of this problem in mod_p
On the subject of duplicate symbol definitions, I ran the script I have
to check for such things against mod_perl and it found a few already,
using mod_perl 1.99_12 (httpd-2.0.49, perl 5.8.3).
mod_perl.so ModPerl/Const/Const.so => modperl_constants_group_lookup_apache
mod_perl.so ModPerl/Const/C
Steve Hay wrote:
As I reported recently, compat/send_fd.t and directive/setupenv.t both
currently (2.0.49 / 5.8.4 / 1.99_14) fail in the test suite on Win32,
but work when tried in isolation.
After a little trial & error, I've found that running apr/pool.t before
them make them fail, i.e.
Steve Hay wrote:
As I reported recently, compat/send_fd.t and directive/setupenv.t both
currently (2.0.49 / 5.8.4 / 1.99_14) fail in the test suite on Win32,
but work when tried in isolation.
After a little trial & error, I've found that running apr/pool.t before
them make them fail
That what t
Geoffrey Young wrote:
Well, populating $r->finfo is not a job of APR::Finfo which must be
independent from httpd.
of course, we both know that.
nevertheless, APR::Finfo::stat() pretty much exists for exactly that purpose
- if a perl user wants to stat a file they already have perl's stat, which
h
As I reported recently, compat/send_fd.t and directive/setupenv.t both
currently (2.0.49 / 5.8.4 / 1.99_14) fail in the test suite on Win32,
but work when tried in isolation.
After a little trial & error, I've found that running apr/pool.t before
them make them fail, i.e.
perl t/TEST compa
> Well, populating $r->finfo is not a job of APR::Finfo which must be
> independent from httpd.
of course, we both know that.
nevertheless, APR::Finfo::stat() pretty much exists for exactly that purpose
- if a perl user wants to stat a file they already have perl's stat, which
has been proven m
16 matches
Mail list logo
