search

ohmage / server

The ohmage server application.
37 stars 25 forks source link

error messages in error document body #270

Closed jeroen closed 10 years ago

jeroen commented 12 years ago

I tested the CORS headers for error pages, and it seems to be working. Maybe it would be a small step to also add some content to these error pages? Currently the errors always come without any content in the response body, eg:

https://dev.mobilizingcs.org/app/config/zzzzz

A long-standing feature request from way back when is to enable a 'debug mode', so that in case of an error, the error message is not just put in aw.log but also returned to the client. That might make debugging a lot easier.

jojenki commented 12 years ago

Right now, when we return a 404 we also return an empty HTML page. Instead, we could add the following to that page which would redirect it back to the root of the web address, which, presumably, is the ohmage homepage:

<html>
  <head>
    <meta http-equiv="Refresh" content="0; URL=/">
  </head>
  <body>
  </body>
</html>
jeroen commented 12 years ago

That's not what I meant. I don't think you should put HTML in there; we use json everywhere to support non-browser clients. Definitely not do the html equivalent of a http 302 when you are returning a 404; that is terribly confusing.

There is no problem with the current stuff. But I thought it might be nice to include some error message (just as plain text) in the body of the http response in case of a 400, 405, etc. If that would be possible, it might be more informative then just the status code. It would definitely make it easier to debug clients because you don't have to dig through aw.log to find out why a call failed.

jojenki commented 11 years ago

This is part of the Open mHealth specification which is what 3.0 will be based off of including properly using HTTP status codes. I am going to move this to 3.0, but it can probably be closed when the 3.0 requirements are being drawn up if we are still going to use the OmH RI to back 3.0.

jshslsky commented 10 years ago

In 3.0, we use the HTTP status codes properly and on 4xx we return a user-friendly plaintext error message.