Re: [Dancer-users] params for post route not working
On Mon, 20 Feb 2012 18:33:11 +0000 GJ <gj@freeshell.org> wrote:
On Mon, Feb 20, 2012 at 10:54:04AM +0000, David Precious wrote:
On Sun, 19 Feb 2012 23:20:48 +0000 GJ <gj@freeshell.org> wrote:
The above example is from the documentation, the result is the `else' redirection. I tried my own code also. params->user is empty, in fact if I dump all `params' its empty.
Interesting. Can you dump the request object returned by the 'request' keyword so we can see what Dancer got?
$VAR1 = bless( { '_read_position' => 0, 'content_length' => '27', 'connection' => 'keep-alive', 'headers' => bless( { 'user-agent' => 'Mozilla/5.0 (Ubuntu; X11; Linux i686; rv:9.0.1) Gecko/20100101 Firefox/9.0.1', 'connection' => 'keep-alive', 'accept' => 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8', 'accept-language' => 'en-us,en;q=0.5', 'cookie' => 'session=5aa3a19de3fdd444d66a0ff1a799cc721a0d72a0; user_name=admin; dancer.session=empty', 'accept-encoding' => 'gzip, deflate', 'content-length' => '27', 'host' => 'localhost', 'accept-charset' => 'ISO-8859-1,utf-8;q=0.7,*;q=0.7', 'content-type' => 'application/x-www-form-urlencoded', 'referer' => 'http://localhost/login' }, 'HTTP::Headers' ), '_http_body' => bless( { 'content_length' => '27', 'tmpdir' => '/tmp', 'buffer' => '', 'state' => 'buffering', 'chunk_buffer' => '', 'body' => undef, 'content_type' => 'application/x-www-form-urlencoded', 'length' => 0, 'chunked' => '', 'upload' => {}, 'param_order' => [], 'param' => {}, 'cleanup' => 1 }, 'HTTP::Body::UrlEncoded' ), '_route_pattern' => '/login', 'accept_encoding' => 'gzip, deflate', '_route_params' => {}, 'is_forward' => 0, 'uploads' => {}, '_body_params' => $VAR1->{'_http_body'}{'param'}, 'body' => '', 'accept_charset' => 'ISO-8859-1,utf-8;q=0.7,*;q=0.7', 'method' => 'POST', 'id' => 1, <snipped rest>
Hmm. It looks like the HTTP body contains content, but presumably hasn't been parsed yet. Are you able to test against Perlover's pull request: https://github.com/sukria/Dancer/pull/702 I'd be interested to know if that helps or not. From the dump above, it looks like the HTTP headers have been parsed already, so I'm not convinced it should make any difference. You said in another mail that this only happens when you run via Apache, not running stand-alone I believe; can you share the Apache config you're using so I can attempt to reproduce the problem? Cheers Dave P -- David Precious ("bigpresh") <davidp@preshweb.co.uk> http://www.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/cpan www.preshweb.co.uk/github
On Tue, Feb 21, 2012 at 09:55:34AM +0000, David Precious wrote:
Hmm. It looks like the HTTP body contains content, but presumably hasn't been parsed yet.
Are you able to test against Perlover's pull request:
I'll do this as soon as I get a chance.
I'd be interested to know if that helps or not. From the dump above, it looks like the HTTP headers have been parsed already, so I'm not convinced it should make any difference.
You said in another mail that this only happens when you run via Apache, not running stand-alone I believe; can you share the Apache config you're using so I can attempt to reproduce the problem?
Yeah, thats easier. I'm using what is specified in Dancer::Deployment: ---- <VirtualHost *:80> ServerName www.example.com DocumentRoot /my/path ServerAdmin you@example.com <Directory "/my/path"> AllowOverride None Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all AddHandler cgi-script .cgi </Directory> ErrorLog /var/log/apache2/www.example.com-error.log CustomLog /var/log/apache2/www.example.com-access_log common </VirtualHost> And .htaccess: ---- # BEGIN dancer application htaccess RewriteEngine On RewriteCond %{SCRIPT_FILENAME} !-d RewriteCond %{SCRIPT_FILENAME} !-f RewriteRule (.*) public/dispatch.cgi$1 [L] # END dancer application htaccess ---- Thanks, GJ
On Tue, Feb 21, 2012 at 09:55:34AM +0000, David Precious wrote:
On Mon, 20 Feb 2012 18:33:11 +0000 GJ <gj@freeshell.org> wrote:
On Mon, Feb 20, 2012 at 10:54:04AM +0000, David Precious wrote:
On Sun, 19 Feb 2012 23:20:48 +0000 GJ <gj@freeshell.org> wrote:
The above example is from the documentation, the result is the `else' redirection. I tried my own code also. params->user is empty, in fact if I dump all `params' its empty.
Interesting. Can you dump the request object returned by the 'request' keyword so we can see what Dancer got?
$VAR1 = bless( { '_read_position' => 0, 'content_length' => '27', 'connection' => 'keep-alive', 'headers' => bless( { 'user-agent' => 'Mozilla/5.0 (Ubuntu; X11; Linux i686; rv:9.0.1) Gecko/20100101 Firefox/9.0.1', 'connection' => 'keep-alive', 'accept' => 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8', 'accept-language' => 'en-us,en;q=0.5', 'cookie' => 'session=5aa3a19de3fdd444d66a0ff1a799cc721a0d72a0; user_name=admin; dancer.session=empty', 'accept-encoding' => 'gzip, deflate', 'content-length' => '27', 'host' => 'localhost', 'accept-charset' => 'ISO-8859-1,utf-8;q=0.7,*;q=0.7', 'content-type' => 'application/x-www-form-urlencoded', 'referer' => 'http://localhost/login' }, 'HTTP::Headers' ), '_http_body' => bless( { 'content_length' => '27', 'tmpdir' => '/tmp', 'buffer' => '', 'state' => 'buffering', 'chunk_buffer' => '', 'body' => undef, 'content_type' => 'application/x-www-form-urlencoded', 'length' => 0, 'chunked' => '', 'upload' => {}, 'param_order' => [], 'param' => {}, 'cleanup' => 1 }, 'HTTP::Body::UrlEncoded' ), '_route_pattern' => '/login', 'accept_encoding' => 'gzip, deflate', '_route_params' => {}, 'is_forward' => 0, 'uploads' => {}, '_body_params' => $VAR1->{'_http_body'}{'param'}, 'body' => '', 'accept_charset' => 'ISO-8859-1,utf-8;q=0.7,*;q=0.7', 'method' => 'POST', 'id' => 1, <snipped rest>
Hmm. It looks like the HTTP body contains content, but presumably hasn't been parsed yet.
Are you able to test against Perlover's pull request:
https://github.com/sukria/Dancer/pull/702
I'd be interested to know if that helps or not. From the dump above, it looks like the HTTP headers have been parsed already, so I'm not convinced it should make any difference.
So, I finally got around to this: I can report that Perlover's version fixes the issue with POSTed params. Thanks, GJ
Hello,
So, I finally got around to this: I can report that Perlover's version fixes the issue with POSTed params.
Thanks for good news ;-) May be patch will be applied to official branch? It waits already 3 months :) Perlover
On Thu, Mar 01, 2012 at 12:13:03PM +0100, Perlover wrote:
Hello,
So, I finally got around to this: I can report that Perlover's version fixes the issue with POSTed params.
Thanks for good news ;-)
May be patch will be applied to official branch? It waits already 3 months :)
OK, things are getting weirder. It's not Perlover's changes per se that fixed the issue. I'm still debugging, but near as I can tell, the issue is related to this... In my vanilla cgi application, I have my homegrown objects like: Vanilla::Foo Vanilla::Bar etc. In my Dancer application's lib directory I had copied them over like: lib/ App.pm Vanilla/ Foo.pm Bar.pm and so forth where, App.pm is my main file. App.pm calls 'Vanilla::Foo', 'Vanilla::Bar', &c. It is at this point that I can't use POSTed params. So in the course of debugging I rearranged my directory structure to be like: lib/ App.pm Foo.pm Bar.pm and I consequently changed App.pm to now call 'Foo', 'Bar', and so on. And then it is at this point that I can see and use POSTed params! I don't think its my Vanilla::Foo code, because I'm not using any methods -- just calling the libraries at the top of App.pm . Does anyone have any idea WTF is going on? I'm continuing to debug, next step will be to actually use the 'Vanilla' libraries' methods and see what happens. Thanks GJ
participants (3)
-
David Precious -
GJ -
Perlover