perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Foertsch <torsten.foert...@gmx.net>
Subject Re: MapToStorage and the use of path_info (was Re: return DECLINED...)
Date Fri, 29 Feb 2008 19:22:55 GMT
On Fri 29 Feb 2008, Frank Maas wrote:
> I am using a mechanism where I use the path_info to carry information
> about the content to be served. However, as far as I know the only way to
> do this is to create a handler that is defined for the correct location.
> In the described situation, something like,
>
> <Location /archive/news>
>   PerlHandler   MyNews->handler()
> </Location>
>
> I do not see how MapToStorage handler will help here. There probably is no
> /var/www/archive/news file (or directory), and even if there is, it is of
> no use to Apache. Or am I completely and utterly mistaken here?

Your confusion comes from the fact that you look at it through mod_perl 
spectacles where you don't necessarily have a corresponding disk file. But 
Apache is made chiefly to ship files.

So in the m2s phase apache splits the filename it gets from trans into the 
name of a filesystem entry and the trailing "path_info".

If you have a CGI script say /bin/x.cgi that is located in /www/cgi-bin/x.cgi 
and you call it as /bin/x.cgi/path/info then after trans filename points 
to /www/cgi-bin/x.cgi/path/info. m2s then finds that /www/cgi-bin/x.cgi is a 
regular file. So it sets filename to /www/cgi-bin/x.cgi and path_info 
to /path/info. So in CGI context you can be certain that PATH_INFO is the 
remainder of the URI after the current script is stripped off.

BTW, the default response handler the one that ships files returns 404 if 
path_info is not empty.

Now in mod_perl you normally don't have a disk file. You have a compiled 
handler. So m2s will determine the start of path_info somewhere in the URI 
where it finds the last existing directory.

Hence when using a modperl handler don't rely on path_info. By creating an 
additional directory or deleting one you can spoil your logic! That is called 
action at a distance.

Use $r->uri and $r->location instead. Don't use <LocationMatch> in this case.

Then the first part of $r->uri equals to $r->location. So you can compute a 
mod_perl version of path_info as "substr($r->uri, length($r->location))". 
This one doesn't depend on existing or non-existing filesystem entries.

Torsten

Mime
View raw message