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) <a...@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. > > >
