On Wed, Mar 11, 2015 at 1:25 PM, David E. Wheeler <da...@justatheory.com> wrote:
> On Mar 11, 2015, at 9:59 AM, David E. Wheeler <da...@justatheory.com> > wrote: > > > # Set the filename. > > my $file = File::Spec->catfile($sub_root, substr $r->uri, 1); > > $r->filename($file); > > $r->finfo(APR::Finfo::stat($file, APR::Const::FINFO_NORM, > $r->pool)); > > return DECLINED; > > } > > > > I have no PerlReponseHandler, so Apache handles the response…and returns > 404. Note that a request for /hi.txt; it’s only a request in a > subdirectory, /foo/bar.html, that fails. Why? Why isn’t Apache able to find > that file? Is there some other attribute of $r I need to set or unset? > > Turns out I was able to fix this issue by unsetting path_info. I just added > > $r->path_info(undef); > > To the above code, and now Apache can find the file. > > I do not understand the relationship between filename (which is often not > the full path to a file) and path_info. Fortunately, it looks like I don’t > have to. But we might want to consider updating the docs to recommend > unsetting path_info when setting the full path to a file in filename. > > That is very curious. What was in path_info before? Is this a difference between undef and ""? Because path_info shouldn't be involved in finding the file, unless Apache is configured to ignore path info. And even that doesn't make sense because you weren't testing with /foo/bar.html/extra/pathinfo You could also check how this directive affects the problem (whether it should be turned off, or if your handler needs accept / deny the path info as with the 'default' argument: AcceptPathInfo On I found this on apache 2.4's docs: http://httpd.apache.org/docs/current/mod/core.html#AcceptPathInfo Best, > > David > >
