> 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
FYI: This is a very important feature in Apache that allows for
dynamic image scripts to function (amongst other things). For
example, I have captcha images stored in a BYTEA column in
PostgreSQL, and I have a custom mod_perl2 script called "captcha"
which, to the general public, simply looks like another directory (if
you want a working example of this script, you can see it in use here
for now: http://www.inter-corporate.com/test/captcha.pl ).
The GET method in HTTP is used to download the image from
/images/captcha/-number-.jpeg which doesn't actually exist anywhere
on the file system. If the number is incorrect (e.g., a row with
that ID number doesn't exist in the SQL table), then my script simply
returns the Apache2 constant for NOT_FOUND.
This technique can be used for other things too, such as the output
of messages in a web-based forum, or calendar events, etc. The end
result is that the address bar is very tidy with numbers or other
identifying information, without need for any special characters like
interrogation marks and equal signs, which can be cryptic to users
who are not computer literate -- the following two example URIs show
the difference between what I consider to be a more user-friendly URI
and a more cryptic [to many non-computer-literate users] URI:
More user-friendly
http://www.example.com/events/2015/02/25/today.pl
More cryptic
http://www.example.com/events.pl?d=20150225&v=today
Even more cryptic
http://www.example.com/events.pl?y=2015&m=2&d=25&v=today
I tend to include the ".pl" suffix as opposed to the ".html" suffix
(or no suffix at all) because I like to promote Perl, but this part
is optional if you want that first link to be even simpler.
The first example.com link above practically speaks for itself, so
users can share such links with little or no explanation of what the
link is for. The second and third example.com links may require some
explanation, and then there are problems where users sometimes remove
the various parameters inadvertently or insert other characters
without noticing that they've done so.
An additional advantage I've encountered with this is that it
effectively offloads GET parameters into the URI, which are processed
via splitting $r->path_info by a slash and then that leaves any POST
parameters from an HTML form for processing more cleanly
behind-the-scenes.
It's really nice because I can parse the last portion, "today.pl"
(from the first example.com link above), and if it was changed to
something like "banner.pl" or "logo.pl" then I could output an image
file instead to serve HTML code output by "today.pl" that references
an image as so: <img src=logo.pl width=65 height=65 border=0>
Using the relative URI, again the processing of $r->path_info
results in my initial "/events" Perl script determining which event
to look at (at least the date in this example, for which an event ID
number could be used instead of the date, etc.) and transmitting the
correct logo file when the web browser sends the request for it.
I hope this information will be of interest to someone.
Randolf Richardson - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
http://www.inter-corporate.com/
