[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-modperl
Subject:    MP 2.0.1 slurp_filename broken?
From:       Bjorn Jacobsen <bjorn () sparkit ! no>
Date:       2005-08-26 9:14:34
Message-ID: 6.2.3.4.2.20050826101818.076bf520 () mail ! sparkit ! no
[Download RAW message or body]

Hello,

After upgrading to mod_perl 2.0.1 (from 1.99) I've got some problem 
with custom script handlers (inherited from ModPerl::Registry) no 
longer reports file access errors. It seems to boil down to the 
$r->slurp_filename() method, which does not throw if the file can't 
be opened/read for some reason, unlike before.

I've done a temproary workaround by patching the read_script in 
ModPer/RegistryCooker.pm, but it's not a good solution...

     $self->debug("reading $self->{FILENAME}") if DEBUG & D_NOISE;
     $self->{CODE} = eval { $self->{REQ}->slurp_filename(0) }; # untainted
+    if (!$@ && !defined($self->{CODE})) {
+        $self->log_error("slurp_filename returned nothing (probable 
err: $!)");
+        return Apache2::Const::NOT_FOUND; # Or whatever, for now. 
NOT_FOUND most likely.
+    }
     if ($@) {
         $self->log_error("$@");

Does anyone have a clue about this? I haven't checked the actual XS 
code for slurp_filename, but I see there is an overload of the method 
in RegistryLoader (which is never being used,
AFAIK, when inheriting from Registry or RegistryCooker).

Platform: httpd 2.0.54, perl 5.8.7, mod_perl 2.0.1, FreeBSD 
4.11-STABLE (reproducacble on my Linux/Debian test server as well).

[prev in list] [next in list] [prev in thread] [next in thread]