Why is Dancer2 mixing POST and GET params?
hi, In the strange case of sending a POST request to http://localhost:5000/echo?a=1&b=2 with the POSTed values b=4 and c=3 the param() function of dancer will return 1 for a, 3 for c as expected and 4 for b. So it overrides the b received in the URL by the b received in the POST, but it also supplies the value for a which is only available in the URL. On the other hand, if the same key is supplied multiple times in the URL (e.g. http://localhost:5000/echo?a=1&b=2&a=6 then param('a') will return an array reference. I wonder wouldn't it be better to have separate param() functions for values received in the URL and values received in the POST request? Or in other words, could someone explain why was the decision to unite these input channels? Gabor ps. This is the code I used: package App::Try; use Dancer2; our $VERSION = '0.1'; use Data::Dumper; get '/' => sub { '<form method="POST" action="/echo?a=1&b=2&a=6"><input name="c" value="3"><input name="b" value="4"><input type="submit">'; }; post '/echo' => sub { return sprintf "%s - %s - %s", Dumper(param('a')), param('b'), param('c'); }; true;
Hey Gabor. On 10/01/2015 9:49 pm, Gabor Szabo wrote:
I wonder wouldn't it be better to have separate param() functions for values received in the URL and values received in the POST request?
You can use the `params` keyword to access the various sources of params including 'query', 'route', or 'body'. eg. my $body_params = params('body'); #hashref of only the body params
Or in other words, could someone explain why was the decision to unite these input channels?
This is what Sinatra does and hence what Dancer does. Hope that helps, Russell.
Hi Gabor, that’s weird but interesting :) Through documentation you can find at http://search.cpan.org/~sukria/Dancer2-0.01/lib/Dancer2/Core/Request.pm#para...) this: *Fetching only params from a given source* If a required source isn't specified, a mixed hashref (or list of key value pairs, in list context) will be returned; this will contain params from all sources (route, query, body). In practical terms, this means that if the param foo is passed both on the querystring and in a POST body, you can only access one of them. If you want to see only params from a given source, you can say so by passing the $source param to params(): my %querystring_params = params('query'); my %route_params = params('route'); my %post_params = params('body'); If source equals route, then only params parsed from the route pattern are returned. If source equals query, then only params parsed from the query string are returned. If source equals body, then only params sent in the request body will be returned. If another value is given for $source, then an exception is triggered. So it means you can get params from different sources. I believe Dancer 1 behaves the same way ( http://search.cpan.org/~xsawyerx/Dancer-1.3110/lib/Dancer/Request.pm ) cheers, Tiago Q On 10 January 2015 at 12:31, Russell Jenkins < russell.jenkins@strategicdata.com.au> wrote:
Hey Gabor.
On 10/01/2015 9:49 pm, Gabor Szabo wrote:
I wonder wouldn't it be better to have separate param() functions for values received in the URL and values received in the POST request?
You can use the `params` keyword to access the various sources of params including 'query', 'route', or 'body'. eg. my $body_params = params('body'); #hashref of only the body params
Or in other words, could someone explain why was the decision to unite
these input channels?
This is what Sinatra does and hence what Dancer does.
Hope that helps, Russell.
_______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
-- Tiago Quintela
participants (3)
-
Gabor Szabo -
Russell Jenkins -
Tiago Quintela