Re: MapToStorage and the use of path_info (was Re: return DECLINED...)

["J. Peng" <pe...@gmail.com>]

I'm still confused why we need a path_info for the additional info to
CGI/modperl scripts?
Generally under CGI we say x.cgi?key=value to pass arguments, under
modperl handler we say /myHandler/?key=value to do it, or using POST
method.
Under what case we use path_info?

//joy

On Sat, Mar 1, 2008 at 3:22 AM, Torsten Foertsch
<to...@gmx.net> wrote:
> 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
>

Re: MapToStorage and the use of path_info (was Re: return DECLINED...)

["J. Peng" <pe...@gmail.com>]

On Sat, Mar 1, 2008 at 1:37 PM, Raymond Wan <rw...@kuicr.kyoto-u.ac.jp> wrote:
>  Not a very technical answer, but maybe an easy way of thinking of
>  things.  The second scenario also makes it possible for Google, etc. to
>  index your web pages since it is a "real" URL.  In the first case, it is
>  possible, but not as straight-forward.
>

oh, it's good that I learned another way to request an uri with the
path_info way.
yes the path_info uri is good to be recorded by google, since it looks
doesn't like a dynamic page.
for us we generally use mod_rewrite to rewrite a dynamic page to seem
like a static page,like:

    RewriteRule  ^/myspace/my(\d+).html  /myspace/index.cgi?id=$1

thanks.

//joy

Re: MapToStorage and the use of path_info (was Re: return DECLINED...)

[Raymond Wan <rw...@kuicr.kyoto-u.ac.jp>]

Joy,

J. Peng wrote:
> I'm still confused why we need a path_info for the additional info to
> CGI/modperl scripts?
> Generally under CGI we say x.cgi?key=value to pass arguments, under
> modperl handler we say /myHandler/?key=value to do it, or using POST
> method.
> Under what case we use path_info?
>   

How about this for an explanation.  In the first scenario with the ?, 
you are passing arguments explicitly using key/value pairs as if it was 
part of the URL sent by the web browser.  In the second scenario, 
nothing is being passed as key/value pairs.  Instead, the server 
searches up/down the directory hierarchy until it finds a match and 
everything after the match becomes the argument.

In the first scenario when you are splitting the path into key/value, 
you need to know where to split it.  How?  Perhaps by doing a file test 
with each split yourself?  In the second case, you don't need to worry 
about it.

Not a very technical answer, but maybe an easy way of thinking of 
things.  The second scenario also makes it possible for Google, etc. to 
index your web pages since it is a "real" URL.  In the first case, it is 
possible, but not as straight-forward.

Ray