AcceptPathInfo usefulness (was: Re: How Do I change the Document Root Per Request)

> On Wed, Mar 11, 2015 at 1:25 PM, David E. Wheeler <[email protected]>
> wrote:
> 
> > On Mar 11, 2015, at 9:59 AM, David E. Wheeler <[email protected]>
> > 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 - [email protected]
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
http://www.inter-corporate.com/