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
Hi Stephen. 2011/7/7 Stephen Fenwick-Paul <stephen@activeg.org>:
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 (snip) Which is OK, but where is the meaningful message to the user gone?
To show the stack trace, show_errors variable in a environment/production.yml shuld be 1. I think so. It's 1 in development.yml. But in production.yml It's 0. best regards. -- Takeshi OKURA
I would also add that this choice is wise, because showing such internal info to the end user in a production environment is likely to be frown during a security audit. Of course this is a general statement that does not take into account what Stephen might have read about how RESTful apps should respond to errors, but I would be surprised of the contrary. Cheers, Flavio. On Thu, Jul 7, 2011 at 1:44 PM, Takeshi OKURA <okura3@gmail.com> wrote:
Hi Stephen.
2011/7/7 Stephen Fenwick-Paul <stephen@activeg.org>:
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 (snip) Which is OK, but where is the meaningful message to the user gone?
To show the stack trace, show_errors variable in a environment/production.yml shuld be 1. I think so.
It's 1 in development.yml. But in production.yml It's 0.
best regards.
-- Takeshi OKURA _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
Thanks for the replies. I think I've not explained myself well. I don't expect the backtrace to be shown or any internal error in production mode, but I do need to be able to pass back to users of the system some meaningful message on why their called failed. Such as "Sorry we have experienced a system failure - please try again later. Your problem has need reported" for a 500, or "Sorry you have not sent the mandatory argument 'type'" or "Sorry, the argument 'ditsance' is not understood." for a 400. How do I get such messages back to the caller, be it a web page, or most problematically a RESTful user using JSON and still re ponded with a meaningful code. I could catch all errors, and send back a nice HTML or JSON object, but my response would be a 200 which seems wrong. At present the poor user can not tell why his requests are failing. thanks again for an guidance. Stephen On Thu, Jul 7, 2011 at 3:04 PM, Flavio Poletti <polettix@gmail.com> wrote:
I would also add that this choice is wise, because showing such internal info to the end user in a production environment is likely to be frown during a security audit.
Of course this is a general statement that does not take into account what Stephen might have read about how RESTful apps should respond to errors, but I would be surprised of the contrary.
Cheers,
Flavio.
On Thu, Jul 7, 2011 at 1:44 PM, Takeshi OKURA <okura3@gmail.com> wrote:
Hi Stephen.
2011/7/7 Stephen Fenwick-Paul <stephen@activeg.org>:
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 (snip) Which is OK, but where is the meaningful message to the user gone?
To show the stack trace, show_errors variable in a environment/production.yml shuld be 1. I think so.
It's 1 in development.yml. But in production.yml It's 0.
best regards.
-- Takeshi OKURA _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
Hello, Le 07/07/2011 21:36, Stephen Fenwick-Paul a écrit : [...]
How do I get such messages back to the caller, be it a web page, or most problematically a RESTful user using JSON and still re ponded with a meaningful code.
I could catch all errors, and send back a nice HTML or JSON object, but my response would be a 200 which seems wrong.
At present the poor user can not tell why his requests are failing.
thanks again for an guidance.
I suggest using Dancer::Plugin::REST for using status_ERROR, like: if ($missing_parameter) { return status_bad_request("Missing parameter $foo"); } Or manually, the send_entity() method: if ($missing_parameter) { return send_entity({ error => "Missing parameter $foo"}, 400); } This how we handle this case at work with our Dancer-powered API webservice. see http://cpansearch.perl.org/src/SUKRIA/Dancer-Plugin-REST-0.06/lib/Dancer/Plu... for details Regards, -- 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
participants (4)
-
Alexis Sukrieh -
Flavio Poletti -
Stephen Fenwick-Paul -
Takeshi OKURA