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: unsubscribe

[Clive Eisen]

Quite

AND the info is in the headers of EVERY email

--
Clive Eisen
GPG: 75056DD0






> On 7 Aug 2017, at 13:39, André Warnier (tomcat)  wrote:
> 
> On 07.08.2017 14:30, Timon Roth wrote:
>> unsubscribe
> 
> See : http://perl.apache.org/maillist/modperl.html#Subscription_Information
> . unsubscribe from the list
> 

Re: unsubscribe

[tomcat]

On 07.08.2017 14:30, Timon Roth wrote:

unsubscribe


See : http://perl.apache.org/maillist/modperl.html#Subscription_Information
. unsubscribe from the list

unsubscribe

[Timon Roth]

unsubscribe

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.
>

about request route

[风河]

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.