Community
Participate
Working Groups
Currently, all uncatched server-side errors (exceptions) thrown in runtime are shown to the end user. A more convenient way is to render these errors with a JSON message and let the client decide how to handle them. More over, with the bug 372296 fixed, we want all responses of a POST requests to be a JSON.
I think it in the responsibility of the servlet engine to handle errors. Doesn't handling exceptions in RWT interfere with or lock out the servlet engines own error handling or with the settings specified in the web-xml <error-page> section?
Hm... interesting. Now I think that we *can't* guarantee that the response of the Ajax (POST) request is *always* a JSON in case of an error. I think it's possible servlet engine to respond to an Ajax request with an error even before RWTServlet getting the request - too long request parameters for example.
The discussion that lead to this bug was only about POST requests to the default service handler. That was not clear from the bug description, so I changed the title accordingly. The result of a POST request is now expected to be JSON (bug 372296), and I think that also in case of errors the result should be in a predefined JSON format. An example that we had in mind is couchdb, which also returns its error messages in JSON, e.g. {"error":"bad_request","reason":"invalid UTF-8 JSON"}. I guess the same pattern applies for many RESTful services. Since the result of a POST will never be displayed to an end user, HTML pages don't make sense here. Neither do custom error handlers. I think we should distinguish at least two kinds of failure states, invalid requests (such unknown object ids, illegal parameters, invalid request counter etc.) and server errors. Invalid requests should always return a 4xx HTTP code and also contain an understandable message. Server errors (such as an IOException etc.) should lead to an HTTP 5xx. Without this distinction, client developers have a hard time testing their custom clients. Currently, we cannot distinguish these kinds of errors, but with the implementation of the client-to-server protocol this will be possible. Maybe it also makes sense to distinguish errors in the framework and in the application code? It's true that we cannot guarantee JSON for all server errors. For example, if a client uses HTTP Basic authentication, the server will probably return an 401 before we receive the request. Not sure if we can or should do anything about this?
Refactored the "invalid request counter" and "session timeout" errors rendering. Now protocol "meta" is used to inform the client about these errors. The following HTTP status code are set on the response for these errors: "invalid request counter" - HTTP status code 412 - Precondition Failed "session timeout" - HTTP status code 403 - Forbidden The 403 was chosen as recommended code for server session timeout - see: http://stackoverflow.com/questions/1653493/what-http-status-code-is-supposed-to-be-used-to-tell-the-client-the-session-has
(In reply to comment #3) > [ ... ] Makes perfect sense to me. Thanks for the clarification. I would not distinguish errors in the framework and in the application. It would a) probably make exception handling more complex and b) I don't see an additional value in the information With the stack-trace of the exception, user should be able to easly find the source of the error.
Created attachment 212233 [details] Proposed patch With this patch, all exception, thrown within the life cycle are catched and logged. A JSON is returned with HTTP status code 500. Maybe we have to adjust the test logger in the RWTLifeCycle2_Test to keep the console clean when executing some tests.
Created attachment 212302 [details] Updated patch Only Exceptions are catched in this patch. ServletLog calss is used for logging.
Created attachment 212303 [details] Updated patch Only Exceptions are catched in this patch. ServletLog class is used for logging.
