FAQ
In my handler I call $r->path_info to determine the path used to call my
script.

I am trying to have a test version of my code using the same module but
which reads different data based on the path.

So I have:


<Location /MyPackage2>
     SetHandler perl-script
     PerlResponseHandler Apache::MyPackage::FrontEnd2
</Location>
<Location /MyPackage2Test>
     SetHandler perl-script
     PerlResponseHandler Apache::MyPackage::FrontEnd2
</Location>

In FrontEnd2....


sub handler {
     my $r =3D shift;
     warn $r->path_info;
     if($r->path_info =3D~ /test/i){
         ## Load test data
     }else{
        ## Load real data
     }

This works for another package I have exactly like this, but in this
case $r->path_info is empty.

I am stumped.

Worik
--
The only true evil is turning people into things....
                                          Granny Weatherwax
        worik.stanton@gmail.com 021-1680650, (03) 4821804
                           Aotearoa (New Zealand)

Search Discussions

  • Jie Gao at Jun 19, 2014 at 1:12 am
    Could it be that after the URI --> filename translation, there is indeed nothing left there?

    A resource referred to by the "Location" directive does not necessarily correspond to a local file.

    Regards,


    Jie



    * Worik Stanton wrote:
    Date: Thu, 19 Jun 2014 12:13:10 +1200
    From: Worik Stanton <worik.stanton@gmail.com>
    To: mod_perl list <modperl@perl.apache.org>
    Subject: $r->path_info unreliable?
    User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
    Thunderbird/24.5.0

    In my handler I call $r->path_info to determine the path used to call my
    script.

    I am trying to have a test version of my code using the same module but
    which reads different data based on the path.

    So I have:


    <Location /MyPackage2>
    SetHandler perl-script
    PerlResponseHandler Apache::MyPackage::FrontEnd2
    </Location>
    <Location /MyPackage2Test>
    SetHandler perl-script
    PerlResponseHandler Apache::MyPackage::FrontEnd2
    </Location>

    In FrontEnd2....


    sub handler {
    my $r =3D shift;
    warn $r->path_info;
    if($r->path_info =3D~ /test/i){
    ## Load test data
    }else{
    ## Load real data
    }

    This works for another package I have exactly like this, but in this
    case $r->path_info is empty.

    I am stumped.

    Worik
    --
    The only true evil is turning people into things....
    Granny Weatherwax
    worik.stanton@gmail.com 021-1680650, (03) 4821804
    Aotearoa (New Zealand)
  • Worik Stanton at Jun 19, 2014 at 1:30 am

    On 19/06/14 13:12, Jie Gao wrote:
    Could it be that after the URI --> filename translation, there is
    indeed nothing left there?

    A resource referred to by the "Location" directive does not
    necessarily correspond to a local file.
    I am not sure. I do not do any translation deliberately.

    <Location /MyPackage/DataHashTest>
         SetHandler perl-script
         PerlResponseHandler Apache::MyPackage::DataHash
    </Location>


    In this case it works. Has the URI --> file name translation done some
    thing different than for...

    <Location /MyPackage2Test>
       SetHandler perl-script PerlResponseHandler
       Apache::MyPackage::FrontEnd2
    </Location>

    Where it does work?

    I do not think I understand URI --> file name translation.

    Worik

    PS I am sorry I sent this message twice. It seemed to bounce from the
    list at my end, and I admit I got a bit confused and thought I had used
    an incorrect address. I emailed the list owner thinking I had failed,
    twice, to get through.
    --
    The only true evil is turning people into things....
                                              Granny Weatherwax
            worik.stanton@gmail.com 021-1680650, (03) 4821804
                               Aotearoa (New Zealand)
  • Jie Gao at Jun 19, 2014 at 2:12 am

    * Worik Stanton wrote:

    Date: Thu, 19 Jun 2014 12:13:10 +1200
    From: Worik Stanton <worik.stanton@gmail.com>
    To: mod_perl list <modperl@perl.apache.org>
    Subject: $r->path_info unreliable?
    User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
    Thunderbird/24.5.0

    In my handler I call $r->path_info to determine the path used to call my
    script.
    It looks to me, on the face of it, that you should use "$r->uri" instead.

    $r->path_info() should return nothing if there is no such a file in the
    local file system that corresponds to that name.

    Regards,



    Jie

    I am trying to have a test version of my code using the same module but
    which reads different data based on the path.

    So I have:


    <Location /MyPackage2>
    SetHandler perl-script
    PerlResponseHandler Apache::MyPackage::FrontEnd2
    </Location>
    <Location /MyPackage2Test>
    SetHandler perl-script
    PerlResponseHandler Apache::MyPackage::FrontEnd2
    </Location>

    In FrontEnd2....


    sub handler {
    my $r =3D shift;
    warn $r->path_info;
    if($r->path_info =3D~ /test/i){
    ## Load test data
    }else{
    ## Load real data
    }

    This works for another package I have exactly like this, but in this
    case $r->path_info is empty.

    I am stumped.

    Worik
    --
    The only true evil is turning people into things....
    Granny Weatherwax
    worik.stanton@gmail.com 021-1680650, (03) 4821804
    Aotearoa (New Zealand)
  • Worik Stanton at Jun 19, 2014 at 3:27 am

    On 19/06/14 14:11, Jie Gao wrote:
    * Worik Stanton wrote:
    Date: Thu, 19 Jun 2014 12:13:10 +1200
    From: Worik Stanton <worik.stanton@gmail.com>
    To: mod_perl list <modperl@perl.apache.org>
    Subject: $r->path_info unreliable?
    User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
    Thunderbird/24.5.0

    In my handler I call $r->path_info to determine the path used to call my
    script.
    It looks to me, on the face of it, that you should use "$r->uri" instead.
    Ah yes. That is true. Thank you for that.

    W
    --
    The only true evil is turning people into things....
                                              Granny Weatherwax
            worik.stanton@gmail.com 021-1680650, (03) 4821804
                               Aotearoa (New Zealand)
  • Torsten Förtsch at Jun 23, 2014 at 7:12 am

    On 19/06/14 02:13, Worik Stanton wrote:
    In my handler I call $r->path_info to determine the path used to
    call my script.

    I am trying to have a test version of my code using the same module
    but which reads different data based on the path.

    So I have:


    <Location /MyPackage2> SetHandler perl-script PerlResponseHandler
    Apache::MyPackage::FrontEnd2 </Location> <Location
    /MyPackage2Test> SetHandler perl-script PerlResponseHandler
    Apache::MyPackage::FrontEnd2 </Location>

    In FrontEnd2....


    sub handler { my $r =3D shift; warn $r->path_info; if($r->path_info
    =3D~ /test/i){ ## Load test data }else{ ## Load real data }

    This works for another package I have exactly like this, but in
    this case $r->path_info is empty.

    I am stumped.
    What many people don't understand is what path_info really is. When
    you get that right, you'll see why it is very fragile and almost
    useless in a modperl context.

    Path_info is computed in the maptostorage phase. Suppose first the
    non-modperl case with a simple configuration that only sets
    DocumentRoot without any Aliases and similar stuff. In that case, the
    request uri is simply appended to DocumentRoot and the result taken as
    the name of a file on disk:

    DocumentRoot: /web/root
    URI: /path/to/index.html

    ==> resulting file name: /web/root/path/to/index.html

    Now, if that's a regular file on disk, everything is fine. What if not?

    You could return a 404 as soon as you figure that out.

    But if /web/root/path exists as a regular file and is configured to be
    a CGI script, then you probably want to call it. In this case, the
    remaining part if the uri, /to/index.html, goes to path_info,
    /web/root/path becomes the filename and HTTPD goes on with the request.

    I am not quite sure what happens if /web/root/path is a directory
    instead of a regular file. But I think, the resulting
    filename/path_info pair would be the same.

    So, the splitting of uri into filename and path_info depends not only
    on the web server configuration but also on the layout of files and
    directories on disk. That's why I said, it's fragile. You create a new
    directory because you want to put some static information there and
    all of the sudden the application stops to work.

    In a modperl context, I think it'd make much more sense to split the
    uri like this:

       filename = docroot . substr(uri, 0, length(location))
       path_info = substr(uri, length(location))

    But that's not easy to achieve in the general case. You must take into
    account all sorts of aliases, <Directory>, <DirectoryMatch>,
    <Location> and <LocationMatch> directives.

    And you must consider that although an apache module can take over the
    maptostorage phase and consequently skip all that <Directory> stuff,
    it cannot avoid the processing of <Location> and <LocationMatch>.
    These are not encapsulated as a separate request phase but simply
    happen between the maptostorage and the headerparser phase. Also,
    there is the problem with subrequests and internal redirects.
    Depending on their type they enter the request processing cycle either
    in the uri translation or the maptostorage phase. And they can (at
    least in earlier httpd versions) skip the header parser phase. So, the
    only place where you could possibly patch up the request accordingly
    is the fixup or type checking phases just before response. But at this
    point so much has already happened to the request (header parser,
    access control, type checking) that to not introduce security bugs
    you'd have to go back to header parser at least. So, there is no way
    for modperl to get it right and sensible from the perl perspective.

    Torsten

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmodperl @
categoriesmodperl, perl
postedJun 19, '14 at 12:13a
activeJun 23, '14 at 7:12a
posts6
users3
websiteperl.apache.org

People

Translate

site design / logo © 2018 Grokbase