Re: [OT] Re: about request route ($r->path_info)

[Randolf Richardson]

Thank you for the correction and clarification (and subject line 
update) -- you provided some excellent and very helpful information.

It's good to know that the AcceptPathInfo directive isn't needed for 
the Location stanza (simpler configurations are my preference after 
all), and your explanation perfectly makes sense.

I'm using the FilesMatch stanza to handle all .pl files (and files 
with no suffix, intentionally presumed to be handled by mod_perl2 
just as .pl files are) instead of the Location stanza, so that's 
likely why the AcceptPathInfo directive is useful in my environment.

> Hi Randolf.
> 
> I mark this OT because it is not directly related to the OP's initial 
> question.
> But maybe a nitpick :
> The httpd documentation on AcceptPathInfo is certainly interesting to read 
> (and in years 
> of working with Apache httpd and mod_perl I have never seen it before), but I 
> believe that 
> your recommendation below is not entirely accurate.
> You do not /need/ to add "AccepPathInfo On", in order to have access to the 
> "path" 
> component in a mod_perl handler.
> And even your example would work perfectly without it.
> That is because the default value of this setting, is already to let the 
> handler decide 
> itself, if the request URI should be accepted or not.
> For example, for your example, if you had this configuration :
> 
> ...
>SetHandler mod_perl
>PerlResponseHandler my::module->handler
> ...
> 
> then, any request with a URI starting with "/profile/" would be honored by 
> Apache, and 
> passed to my::module::handler(), and it would be my::module::handler() which 
> gets to 
> decide what to do with whatever follows the leading "/profile/".
> Including obtaining the rest of that URI (via $r->uri or $r->path_info), 
> parse it, 
> interpret it as parameters or not, reject it with a 404, or whatever.
> With the Location above, Apache httpd won't even /look/ at whether this path 
> really exists 
> on the filesystem, which means that the AcceptPathInfo, whatever its setting 
> is, won't 
> even come into play (it also does not hurt, whatever you set it to).
> It only plays a role, when the response handler is /not/ yours (like in the 
> filter example 
> shown in the httpd documentation), and you want to override whathever this 
> other handler 
> would normally do in that case.
> 
> To tell the entire truth, I have not really tested the above specifically. 
> But that is 
> what the documentation (and my apache/mod_perl experience) tells me.
> (I do many things with paths also, and have never needed this setting before).
> 
> On 07.08.2017 18:53, Randolf Richardson wrote:
> > In your "httpd.conf" file (for your VirtualHost if you're using
> > virtual hosts) you'll need to add this line:
> >
> > AcceptPathInfoOn
> >
> > Then you may find the documentation surrounding $r->path_info to be
> > of particular interest, which you can read about here:
> >
> > 
> > https://perl.apache.org/docs/2.0/api/Apache2/RequestRec.html#C_path_info_
> >
> > I use this to implement simple URIs on sites that look like
> > "/profile/29862938728" instead of "/profile?id=29862938728" to make
> > it easier for users to share links.  Based on your question, it seems
> > to me that you're wanting to know how to do something like this.
> >
> > Of course, you'll need to write your own Perl code to handle these
> > requests, and I suspect that's likely what you're wanting to do.  One
> > thing I find very helpful in having done this myself is the use of
> > the 404 response code when the data is wrong (e.g., the profile ID
> > number does not exist in the database) because then the web server
> > just passes everything along to whatever I have configured separately
> > for the 404 handler (this is important because it properly
> > communicates to search engine spiders and other automated systems
> > that the page doesn't exist and should be ignored).
> >
> >> Hi,
> >>
> >> for this like request:
> >> curl http://dns-api.org//dns-api.org
> >>
> >> in Dancer we could write:
> >>
> >> get '/:type/:domain/?' => sub {
> >>
> >>  my $rtype  = params->{ 'type' };
> >>  my $domain = params->{ 'domain' };
> >>
> >>
> >> But in a MP handler, how could we get the similiar result, treating
> >> request path as GET/POST arguments?
> >> thanks.
> >>
> >
> >
> > Randolf Richardson - rand...@inter-corporate.com
> > Inter-Corporate Computer & Network Services, Inc.
> > Beautiful British Columbia, Canada
> > http://www.inter-corporate.com/
> >
> >
> 


Randolf Richardson - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
http://www.inter-corporate.com/

Re: about request route

[风河]

Anyway I have tranformed this opensource project:

https://github.com/skx/dns-api.org

which is powered by dancer, to mod_perl.

the API address:

http://h.dnsbed.com/$type/$host

which is entirely mod_perl backend. :)



On Tue, Aug 8, 2017, at 09:45 AM, 风河 wrote:
> Thanks for all helps.
> 
> On Mon, Aug 7, 2017, at 08:26 PM, André Warnier (tomcat) wrote:
> > On 07.08.2017 13:18, 风河 wrote:
> > > Hi,
> > >
> > > for this like request:
> > > curlhttp://dns-api.org//dns-api.org
> > >
> > > in Dancer we could write:
> > >
> > > get '/:type/:domain/?' => sub {
> > >
> > >  my $rtype  = params->{ 'type' };
> > >  my $domain = params->{ 'domain' };
> > >
> > >
> > > But in a MP handler, how could we get the similiar result, treating 
> > > request path as
> > > GET/POST arguments?
> > >
> > 
> > Well, fundamentally you could not treat the request path, transparently,
> > as a GET/POST 
> > argument. That is precisely the kind of thing which a framework such as
> > Dancer allows you 
> > to do : "abstracting" the fundamental difference which exists at the HTTP
> > level (and the 
> > Apache httpd level) between a request path and e.g. the parameters in a
> > query string, and 
> > make them "kind of look the same" to an application, using some elegant
> > syntax.
> > 
> > In a mod_perl handler, you would do this :
> > 
> > my $r = shift; # Request object
> > my $uri = $r->uri; # gets "//dns-api.org"
> > my ($nothing,$type,$domain) = split('/',$uri);
> > 
> > # or, if you insist on treating the HTTP request path parts as
> > "arguments" :
> > my @args = split('/',$uri);
> > @args = grep(!~#/#,@args);
> > my $params = {
> > 'type' => $args[0],
> > 'domain' => $args[1],
> > };
> > # (I'm sure there is a more elegant way to do this)
> > 
> > mod_perl is not a framework. It gives you access from perl to the Apache
> > internals, as 
> > they are deep down, but it does not "abstract" anything. For Apache
> > "//dns-api.org" is 
> > a request URI, it is not "GET/POST arguments". If this URI does not
> > contain a "?", then 
> > the whole URI is a path. If it does contain a "?", then the part before
> > the "?" is a path, 
> > and the part after it is a query-string, which may or may not contain
> > key/value pairs 
> > which could be "parameters". Those are the underlying "apache objects",
> > when apache has 
> > parsed the request.
> > mod_perl gives you access to these URI, path, and query-string objects of
> > apache, but it 
> > does not "abstract" them further.
> > 
> > Dancer (and other frameworks) are different : their users want some way
> > by which they can 
> > treat path components as "arguments" ? so let's provide them with some
> > way of doing this, 
> > elegantly if possible. But behind the scenes, they do exactly as above.
> > It's just that as 
> > a user, you don't see that.
> > 
> > 

[OT] Re: about request route ($r->path_info)

[tomcat]

Hi Randolf.

I mark this OT because it is not directly related to the OP's initial question.
But maybe a nitpick :
The httpd documentation on AcceptPathInfo is certainly interesting to read (and in years 
of working with Apache httpd and mod_perl I have never seen it before), but I believe that 
your recommendation below is not entirely accurate.
You do not /need/ to add "AccepPathInfo On", in order to have access to the "path" 
component in a mod_perl handler.

And even your example would work perfectly without it.
That is because the default value of this setting, is already to let the handler decide 
itself, if the request URI should be accepted or not.

For example, for your example, if you had this configuration :

...
  SetHandler mod_perl
  PerlResponseHandler my::module->handler
...

then, any request with a URI starting with "/profile/" would be honored by Apache, and 
passed to my::module::handler(), and it would be my::module::handler() which gets to 
decide what to do with whatever follows the leading "/profile/".
Including obtaining the rest of that URI (via $r->uri or $r->path_info), parse it, 
interpret it as parameters or not, reject it with a 404, or whatever.
With the Location above, Apache httpd won't even /look/ at whether this path really exists 
on the filesystem, which means that the AcceptPathInfo, whatever its setting is, won't 
even come into play (it also does not hurt, whatever you set it to).
It only plays a role, when the response handler is /not/ yours (like in the filter example 
shown in the httpd documentation), and you want to override whathever this other handler 
would normally do in that case.


To tell the entire truth, I have not really tested the above specifically. But that is 
what the documentation (and my apache/mod_perl experience) tells me.

(I do many things with paths also, and have never needed this setting before).

On 07.08.2017 18:53, Randolf Richardson wrote:

In your "httpd.conf" file (for your VirtualHost if you're using
virtual hosts) you'll need to add this line:

AcceptPathInfoOn

Then you may find the documentation surrounding $r->path_info to be
of particular interest, which you can read about here:


https://perl.apache.org/docs/2.0/api/Apache2/RequestRec.html#C_path_info_

I use this to implement simple URIs on sites that look like
"/profile/29862938728" instead of "/profile?id=29862938728" to make
it easier for users to share links.  Based on your question, it seems
to me that you're wanting to know how to do something like this.

Of course, you'll need to write your own Perl code to handle these
requests, and I suspect that's likely what you're wanting to do.  One
thing I find very helpful in having done this myself is the use of
the 404 response code when the data is wrong (e.g., the profile ID
number does not exist in the database) because then the web server
just passes everything along to whatever I have configured separately
for the 404 handler (this is important because it properly
communicates to search engine spiders and other automated systems
that the page doesn't exist and should be ignored).


Hi,

for this like request:
curl http://dns-api.org//dns-api.org

in Dancer we could write:

get '/:type/:domain/?' => sub {

 my $rtype  = params->{ 'type' };
 my $domain = params->{ 'domain' };


But in a MP handler, how could we get the similiar result, treating
request path as GET/POST arguments?
thanks.




Randolf Richardson - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
http://www.inter-corporate.com/

Re: about request route

[风河]

Thanks for all helps.

On Mon, Aug 7, 2017, at 08:26 PM, André Warnier (tomcat) wrote:
> On 07.08.2017 13:18, 风河 wrote:
> > Hi,
> >
> > for this like request:
> > curlhttp://dns-api.org//dns-api.org
> >
> > in Dancer we could write:
> >
> > get '/:type/:domain/?' => sub {
> >
> >  my $rtype  = params->{ 'type' };
> >  my $domain = params->{ 'domain' };
> >
> >
> > But in a MP handler, how could we get the similiar result, treating request 
> > path as
> > GET/POST arguments?
> >
> 
> Well, fundamentally you could not treat the request path, transparently,
> as a GET/POST 
> argument. That is precisely the kind of thing which a framework such as
> Dancer allows you 
> to do : "abstracting" the fundamental difference which exists at the HTTP
> level (and the 
> Apache httpd level) between a request path and e.g. the parameters in a
> query string, and 
> make them "kind of look the same" to an application, using some elegant
> syntax.
> 
> In a mod_perl handler, you would do this :
> 
> my $r = shift; # Request object
> my $uri = $r->uri; # gets "//dns-api.org"
> my ($nothing,$type,$domain) = split('/',$uri);
> 
> # or, if you insist on treating the HTTP request path parts as
> "arguments" :
> my @args = split('/',$uri);
> @args = grep(!~#/#,@args);
> my $params = {
>   'type' => $args[0],
>   'domain' => $args[1],
>   };
> # (I'm sure there is a more elegant way to do this)
> 
> mod_perl is not a framework. It gives you access from perl to the Apache
> internals, as 
> they are deep down, but it does not "abstract" anything. For Apache
> "//dns-api.org" is 
> a request URI, it is not "GET/POST arguments". If this URI does not
> contain a "?", then 
> the whole URI is a path. If it does contain a "?", then the part before
> the "?" is a path, 
> and the part after it is a query-string, which may or may not contain
> key/value pairs 
> which could be "parameters". Those are the underlying "apache objects",
> when apache has 
> parsed the request.
> mod_perl gives you access to these URI, path, and query-string objects of
> apache, but it 
> does not "abstract" them further.
> 
> Dancer (and other frameworks) are different : their users want some way
> by which they can 
> treat path components as "arguments" ? so let's provide them with some
> way of doing this, 
> elegantly if possible. But behind the scenes, they do exactly as above.
> It's just that as 
> a user, you don't see that.
> 
> 

Re: about request route ($r->path_info)

[Randolf Richardson]

In your "httpd.conf" file (for your VirtualHost if you're using 
virtual hosts) you'll need to add this line:

AcceptPathInfoOn

Then you may find the documentation surrounding $r->path_info to be 
of particular interest, which you can read about here:


https://perl.apache.org/docs/2.0/api/Apache2/RequestRec.html#C_path_info_

I use this to implement simple URIs on sites that look like 
"/profile/29862938728" instead of "/profile?id=29862938728" to make 
it easier for users to share links.  Based on your question, it seems 
to me that you're wanting to know how to do something like this.

Of course, you'll need to write your own Perl code to handle these 
requests, and I suspect that's likely what you're wanting to do.  One 
thing I find very helpful in having done this myself is the use of 
the 404 response code when the data is wrong (e.g., the profile ID 
number does not exist in the database) because then the web server 
just passes everything along to whatever I have configured separately 
for the 404 handler (this is important because it properly 
communicates to search engine spiders and other automated systems 
that the page doesn't exist and should be ignored).

> Hi,
> 
> for this like request:
> curl http://dns-api.org//dns-api.org
> 
> in Dancer we could write:
> 
> get '/:type/:domain/?' => sub {
> 
> my $rtype  = params->{ 'type' };
> my $domain = params->{ 'domain' };
> 
> 
> But in a MP handler, how could we get the similiar result, treating
> request path as GET/POST arguments?
> thanks.
> 


Randolf Richardson - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Beautiful British Columbia, Canada
http://www.inter-corporate.com/

Re: about request route

[John Dunlap]

This is what I do in our application, using a module that we created
in-house:
my $registry = ServiceRegistry->new;
$registry->register('SERVICE1', '/api/rest/service1/{param1}/list');
my $service = $registry->find($r->uri); # $r->uri returns
'/api/rest/service1/5732/list'
print "$service\n"; # Prints "SERVICE1"
my $parameters = $registry->extract_parameters($r->uri); # $r->uri returns
'/api/rest/service1/5732/list'
print $parameters->{'param1'} . "\n"; # Prints 5732

I'm just registering scalars in this example but the module allows you to
register anything, including an object reference, but we store the key name
of the REST endpoint that we want to hit and then use the key to pull it
out of an inversion of control container. I've posted this to the list
before but there didn't seem to be any interest. If this would be helpful
to you, I'd be happy to send you the code. At it's core, it parses the URI
and uses the keys to descend through the tree of registered services.


On Mon, Aug 7, 2017 at 10:22 AM, Mithun Bhattacharya 
wrote:

> Another way to look at this is Apache has hooks for the location - that is
> the URI you are requesting. Apache doesn't care whether you do a GET or a
> POST/PUT to it and it is left to the underlying subsytems to manage it -
> which is your case would be mod_perl. You can easily have the handler do a
> if/else block based on the $r->method(). You can actually say that if
> $r->method() eq 'POST' return HTTP_BAD_REQUEST or even tailor the response
> to the OPTIONS request method.
>
> On Mon, Aug 7, 2017 at 7:26 AM, André Warnier (tomcat) 
> wrote:
>
>> On 07.08.2017 13:18, 风河 wrote:
>>
>>> Hi,
>>>
>>> for this like request:
>>> curlhttp://dns-api.org//dns-api.org
>>>
>>> in Dancer we could write:
>>>
>>> get '/:type/:domain/?' => sub {
>>>
>>>  my $rtype  = params->{ 'type' };
>>>  my $domain = params->{ 'domain' };
>>>
>>>
>>> But in a MP handler, how could we get the similiar result, treating
>>> request path as
>>> GET/POST arguments?
>>>
>>>
>> Well, fundamentally you could not treat the request path, transparently,
>> as a GET/POST argument. That is precisely the kind of thing which a
>> framework such as Dancer allows you to do : "abstracting" the fundamental
>> difference which exists at the HTTP level (and the Apache httpd level)
>> between a request path and e.g. the parameters in a query string, and make
>> them "kind of look the same" to an application, using some elegant syntax.
>>
>> In a mod_perl handler, you would do this :
>>
>> my $r = shift; # Request object
>> my $uri = $r->uri; # gets "//dns-api.org"
>> my ($nothing,$type,$domain) = split('/',$uri);
>>
>> # or, if you insist on treating the HTTP request path parts as
>> "arguments" :
>> my @args = split('/',$uri);
>> @args = grep(!~#/#,@args);
>> my $params = {
>> 'type' => $args[0],
>> 'domain' => $args[1],
>> };
>> # (I'm sure there is a more elegant way to do this)
>>
>> mod_perl is not a framework. It gives you access from perl to the Apache
>> internals, as they are deep down, but it does not "abstract" anything. For
>> Apache "//dns-api.org" is a request URI, it is not "GET/POST
>> arguments". If this URI does not contain a "?", then the whole URI is a
>> path. If it does contain a "?", then the part before the "?" is a path, and
>> the part after it is a query-string, which may or may not contain key/value
>> pairs which could be "parameters". Those are the underlying "apache
>> objects", when apache has parsed the request.
>> mod_perl gives you access to these URI, path, and query-string objects of
>> apache, but it does not "abstract" them further.
>>
>> Dancer (and other frameworks) are different : their users want some way
>> by which they can treat path components as "arguments" ? so let's provide
>> them with some way of doing this, elegantly if possible. But behind the
>> scenes, they do exactly as above. It's just that as a user, you don't see
>> that.
>>
>>
>>
>


-- 
John Dunlap
*CTO | Lariat *

*Direct:*
*j...@lariat.co *

*Customer Service:*
877.268.6667
supp...@lariat.co

Re: about request route

[Mithun Bhattacharya]

Another way to look at this is Apache has hooks for the location - that is
the URI you are requesting. Apache doesn't care whether you do a GET or a
POST/PUT to it and it is left to the underlying subsytems to manage it -
which is your case would be mod_perl. You can easily have the handler do a
if/else block based on the $r->method(). You can actually say that if
$r->method() eq 'POST' return HTTP_BAD_REQUEST or even tailor the response
to the OPTIONS request method.

On Mon, Aug 7, 2017 at 7:26 AM, André Warnier (tomcat) 
wrote:

> On 07.08.2017 13:18, 风河 wrote:
>
>> Hi,
>>
>> for this like request:
>> curlhttp://dns-api.org//dns-api.org
>>
>> in Dancer we could write:
>>
>> get '/:type/:domain/?' => sub {
>>
>>  my $rtype  = params->{ 'type' };
>>  my $domain = params->{ 'domain' };
>>
>>
>> But in a MP handler, how could we get the similiar result, treating
>> request path as
>> GET/POST arguments?
>>
>>
> Well, fundamentally you could not treat the request path, transparently,
> as a GET/POST argument. That is precisely the kind of thing which a
> framework such as Dancer allows you to do : "abstracting" the fundamental
> difference which exists at the HTTP level (and the Apache httpd level)
> between a request path and e.g. the parameters in a query string, and make
> them "kind of look the same" to an application, using some elegant syntax.
>
> In a mod_perl handler, you would do this :
>
> my $r = shift; # Request object
> my $uri = $r->uri; # gets "//dns-api.org"
> my ($nothing,$type,$domain) = split('/',$uri);
>
> # or, if you insist on treating the HTTP request path parts as "arguments"
> :
> my @args = split('/',$uri);
> @args = grep(!~#/#,@args);
> my $params = {
> 'type' => $args[0],
> 'domain' => $args[1],
> };
> # (I'm sure there is a more elegant way to do this)
>
> mod_perl is not a framework. It gives you access from perl to the Apache
> internals, as they are deep down, but it does not "abstract" anything. For
> Apache "//dns-api.org" is a request URI, it is not "GET/POST
> arguments". If this URI does not contain a "?", then the whole URI is a
> path. If it does contain a "?", then the part before the "?" is a path, and
> the part after it is a query-string, which may or may not contain key/value
> pairs which could be "parameters". Those are the underlying "apache
> objects", when apache has parsed the request.
> mod_perl gives you access to these URI, path, and query-string objects of
> apache, but it does not "abstract" them further.
>
> Dancer (and other frameworks) are different : their users want some way by
> which they can treat path components as "arguments" ? so let's provide them
> with some way of doing this, elegantly if possible. But behind the scenes,
> they do exactly as above. It's just that as a user, you don't see that.
>
>
>

Re: about request route

[tomcat]

On 07.08.2017 13:18, 风河 wrote:

Hi,

for this like request:
curlhttp://dns-api.org//dns-api.org

in Dancer we could write:

get '/:type/:domain/?' => sub {

 my $rtype  = params->{ 'type' };
 my $domain = params->{ 'domain' };


But in a MP handler, how could we get the similiar result, treating request 
path as
GET/POST arguments?



Well, fundamentally you could not treat the request path, transparently, as a GET/POST 
argument. That is precisely the kind of thing which a framework such as Dancer allows you 
to do : "abstracting" the fundamental difference which exists at the HTTP level (and the 
Apache httpd level) between a request path and e.g. the parameters in a query string, and 
make them "kind of look the same" to an application, using some elegant syntax.


In a mod_perl handler, you would do this :

my $r = shift; # Request object
my $uri = $r->uri; # gets "//dns-api.org"
my ($nothing,$type,$domain) = split('/',$uri);

# or, if you insist on treating the HTTP request path parts as "arguments" :
my @args = split('/',$uri);
@args = grep(!~#/#,@args);
my $params = {
'type' => $args[0],
'domain' => $args[1],
};
# (I'm sure there is a more elegant way to do this)

mod_perl is not a framework. It gives you access from perl to the Apache internals, as 
they are deep down, but it does not "abstract" anything. For Apache "//dns-api.org" is 
a request URI, it is not "GET/POST arguments". If this URI does not contain a "?", then 
the whole URI is a path. If it does contain a "?", then the part before the "?" is a path, 
and the part after it is a query-string, which may or may not contain key/value pairs 
which could be "parameters". Those are the underlying "apache objects", when apache has 
parsed the request.
mod_perl gives you access to these URI, path, and query-string objects of apache, but it 
does not "abstract" them further.


Dancer (and other frameworks) are different : their users want some way by which they can 
treat path components as "arguments" ? so let's provide them with some way of doing this, 
elegantly if possible. But behind the scenes, they do exactly as above. It's just that as 
a user, you don't see that.

Re: about request route

[Lathan Bidwell]

Hello,

MP does not by default include a routing engine like Dancer or Mojo or
other frameworks.

There are routing engines available (but I'm not very familair with them).

For a pure MP option, see this example from something I've done:

$base_uri = "/app/"
uri = /app/type//domain/dns-api.org/



   my $uri = $r->uri();
> # Remove the base uri from the uri
> $uri =~ s/^$base_uri//g;
> # Split the components out by '/'
> my @components = split(/\//, $uri);
>  # Take all the components and make the odd ones the names and the
> even ones
>  # the values in the CGI query object
> while (@components)
> {
> $components[1] =~ s/\|/\//g;
> $q->param(-name => shift(@components), -value =>
> shift(@components));
> }
> }



*Lathan Bidwell*

Web Programmer
Division of Integrated Marketing & Communication
Andrews University

269-471-6313
*office*www.andrews.edu

"Seek Knowledge.  Affirm Faith.  Change the World."



On Mon, Aug 7, 2017 at 7:18 AM, 风河  wrote:

> Hi,
>
> for this like request:
> curl http://dns-api.org//dns-api.org
>
> in Dancer we could write:
>
> get '/:type/:domain/?' => sub {
>
> my $rtype  = params->{ 'type' };
> my $domain = params->{ 'domain' };
>
>
> But in a MP handler, how could we get the similiar result, treating
> request path as GET/POST arguments?
>
> thanks.
>