Mailing List Archive

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/AAAA/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, ?? <me@fenghe.org> wrote:

> Hi,
>
> for this like request:
> curl http://dns-api.org/AAAA/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.
>

On 07.08.2017 13:18, ?? wrote:
> Hi,
>
> for this like request:
> curlhttp://dns-api.org/AAAA/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 "/AAAA/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 "/AAAA/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.

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) <aw@ice-sa.com>
wrote:

> On 07.08.2017 13:18, ?? wrote:
>
>> Hi,
>>
>> for this like request:
>> curlhttp://dns-api.org/AAAA/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 "/AAAA/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 "/AAAA/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.
>
>
>

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 <mithnb@gmail.com>
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) <aw@ice-sa.com>
> wrote:
>
>> On 07.08.2017 13:18, ?? wrote:
>>
>>> Hi,
>>>
>>> for this like request:
>>> curlhttp://dns-api.org/AAAA/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 "/AAAA/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 "/AAAA/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:*
*john@lariat.co <john@lariat.co>*

*Customer Service:*
877.268.6667
support@lariat.co

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/AAAA/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 "/AAAA/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
> "/AAAA/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.
>
>

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/AAAA/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 "/AAAA/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
> > "/AAAA/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.
> >
> >