- dancer-users - lists.preshweb.co.uk

http put to upload large file
by halayudha 05 Aug '11

05 Aug '11

hi, i have problem to upload file using HTTP PUT with large file 800MB. i use 'upload', which is alright for small file size. may be some one can enlighten me with regard to my issue? juniarto halayudha

5 9

Possible Dancer::Plugin::Ajax bug
by Dave Seleno 05 Aug '11

05 Aug '11

In my Dancer application, I have three different handlers for the same path, based on the request method: ajax '/some_path' => sub { ... return to_json({...}) ; } post '/some_path' => sub { ... return redirect '/some_path' ; } get '/some_path' => sub { ... return template 'some/template' => { ... } ; } What I am seeing is that, occasionally and with no pattern I've yet been able to reproduce, when a GET is issued to /some_path, the process is handled by the correct GET handler, but the response comes back without the layout. There are no errors in the log. From the documentation of Dancer::Plugin::Ajax, disabling the layout is what one would expect only when the AJAX handler was triggered. Issuing another GET immediately after typically "fixes" the problem and the response comes back with the layout intact. Has anyone else experienced this? Regards, Dave

1 0

RPC and Exception Handling
by Tim King 02 Aug '11

02 Aug '11

Hi, all. We're developing an XML-RPC web service using Dancer, and I thought one of you might be able to give us some pointers. We thought that developing an XML-RPC serializer would be the right approach. The serializer would decode the XML-RPC request and encode the XML-RPC response. However, we ran into a couple problems: 1. An RPC request contains a method name, as well as the method parameters. On deserialization, the RPC serializer would have to rewrite the request object, modifying the request path as specified by RPC method contained in the request body. However, the Dancer serializer API only allows the serializer to set request parameters, but not other fields of the request. The only way the serializer can modify the request path is to do so as a side-effect, via Dancer::SharedData, which strikes me as poor design. 2. Certain error conditions in the serializer and in the request handler need to be able to generate an RPC fault message. In particular, we'd like to be able to throw exceptions and have them caught by the infrastructure, which would then convert them to appropriate RPC fault messages. But Dancer doesn't seem to have any way to catch exceptions thrown from handlers or to insert app-specific code into the Dancer call graph. We can't even subclass Dancer::Route, for example, and extend it, because Dancer provides no way to inject our app-specific classes into Dancer's framework. (We were particularly disappointed at this discovery.) So the approach we're working on now is to use an RPC plugin. This plugin decodes the RPC request, creates a new request object for the RPC method, then calls Dancer::Handler->handle_request() to route it to the correct handler. Then it encodes the response back into the corresponding RPC response format. The plugin code will also catch exceptions that the handlers throw, converting them as appropriate into RPC faults. Comments? Do you think we're on the right track? Thanks, -TimK

2 1

What's wrong with Dancer add-ons on search.cpan.org?
by Flavio Poletti 02 Aug '11

02 Aug '11

Hi, some time ago I noticed that three modules of mine related to Dancer had a one-star rating when browsed from search.cpan.org. Curious about these bad rating, I tried to look at the reviews but I found none. I tried to write to both search.cpan.org and perl.org contacts with no answer (possibly due to the vacation-intensive period, but some autoresponder would have been appreciated). After 10 days the bad ratings are still there, so I was curious to see whether I was the only one impacted and I discovered that I'm not. Most Dancer extensions have one-star ratings and no review at all, even though there seem to be reviews according to the search page. E.g. see http://search.cpan.org/search?m=all&q=dancer&s=41 What do you think about it? What can we do? Cheers, Flavio.

5 5

dancer script doesn't work in strawberry perl on windows
by Charlie Gonzalez 31 Jul '11

31 Jul '11

Hi, When attempting to create a Dancer project, the dancer script doesn't create a project directory and instead displays the help page. C:\Users\cgonzalez\Desktop>dancer -a Addressit Usage: dancer [options] -a <appname> Options: -h, --help : print what you are currently reading -a, --application : the name of your application -p, --path : the path where to create your application (current directory if not specified) -x, --no-check : don't check for the latest version of Dancer (checking version implies internet connection) -v, --version : print the version of dancer being used Please advise. -- Charlie Gonzalez (E) itcharlie(a)gmail.com http://itcharlie.blogspot.com/ https://github.com/itcharlie

2 3

Current State of Dancer::Script
by Carlos Ivan Sosa 29 Jul '11

29 Jul '11

I wrote a post of the status of Dancer::Script, which is basically most of my work for GSoC this year. I haven't finished, but I'm more than done with what was needed. Well, enough of description of what the post is about. You can read more about it in my current post of the current state of my work. http://log.gnusosa.net/code/gsoc/dancer-script-state My intention with these post is to get the core team to check it, and see if it can be merged to Dancer's repo in github. Franck Cuny, rebased my work, so my current repo is up-to-date with Sukria's Dancer repo.

2 1

+1 Dancer on MetaCPAN.org
by sawyer x 29 Jul '11

29 Jul '11

Hey all, you can now login to MetaCPAN.org with your PAUSEID, Github, Facebook or Twitter. It takes 3 seconds altogether. Once logged in, you can +1 distributions to notify you like them and/or you think they're helpful/cool/worthwhile/fluffy! Feel free (and please do) +1 Dancer dist! Have a great weekend, S.

3 3

Dancing Corona?
by Chip Salzenberg 29 Jul '11

29 Jul '11

Corona uses Coro, which is a style of Perl threading that has much to recommend it. However, code not designed for it may not function well. In particular, global state is a danger. Given that Dancer uses global state implicitly in such functions as param(), can it even in theory work with Corona? Has anyone tried? Perspiring minds want to know.

2 1

security release 1.3071
by Alexis Sukrieh 28 Jul '11

28 Jul '11

Hello fellow Dancers. We've been notified about a security issue that affects Dancer 1.3070. Indeed, since 1.3070, it was possible to abuse the static file serving feature to obtain files from a directory immediately above the directory configured to serve static files from. This issue has been reported by Vladimir Lettiev and fixed by David Precious. Note that we've added more tests in the suite to make sure this issue cannot come back in future releases. I've published a security release yesterday: 1.3071 which provides the very patch needed to solve the issue. Also be aware that the diff between 1.3070 and 1.3071 is minimal, it only provides the security fix: http://search.cpan.org/diff?from=Dancer-1.3070&to=Dancer-1.3071 We strongly advice you to upgrade to 1.3071 if you're running under 1.3070 in production. http://search.cpan.org/CPAN/authors/id/S/SU/SUKRIA/Dancer-1.3071.tar.gz Thanks for your trust, and happy dancing. -- Alexis Sukrieh -+- Hackers gonna hack! “The problem with quotes on the Internet is that you can't always be sure of their authenticity.” -- Abraham Lincoln http://sukria.net http://twitter.com/sukria

1 0

Confused on error reporting
by Stephen Fenwick-Paul 25 Jul '11

25 Jul '11

Hi all, I've done some reading on how RESTful apps should respond to errors, but I'm getting confused on how Dancer handles this for me. My simple app: package Test; use Dancer ':syntax'; use Dancer::Plugin::Ajax; # Case 1: Just a normal web page with layout get '/error.html' => sub { eval { die "HTML die"; } or do { send_error("HTML: You made a mistake", 400); }; }; # Case 2: A json call get '/error.json' => sub { set serializer => 'JSON'; eval { die "JSON die"; } or do { send_error("JSON: You made a mistake", 400); }; }; # Case 3: HTML being return from an ajax call, thus no layout ajax '/error.html' => sub { eval { die "AJAX die"; } or do { send_error("AJAX: You made a mistake", 400); }; }; With the environment set to development, each of these responds as I expect. Case 1 gives me a full backtrace, case 2 gives me a a json with just the error message, and case 3 again give me a full backtrace, Now moving to the production environment. I get $ curl http://127.0.0.1:3000/error.html <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html> <head> <title>Error 400</title> <link rel="stylesheet" href="/css/style.css" /> <meta http-equiv="Content-type" content="text/html; charset=utf-8" /> </head> <body> <h1>Error 400</h1> <div id="content"> <h2>Unable to process your query</h2>The page you requested is not available </div> <div id="footer"> Powered by <a href="http://perldancer.org/">Dancer</a> 1.3060 </div> </body> Which is OK, but where is the meaningful message to the user gone? $ curl http://127.0.0.1:3000/error.json "An internal error occured" Again, not very useful. $ curl -H 'X-Requested-With: XMLHttpRequest' http://127.0.0.1:3000/error.html "An internal error occured" I need to send something more than this back to the client. What am I doing wrong? If I declare my own error template: set error_template => 'error'; Then, again, in development every thing is as expected, but in production I get "An internal error occured" in all 3 cases. My production,yml is the standard one. Thanks for any insights. Stephen P.S. occured should be occurred

4 4