Inconsistencies in error handling between backends

[bergmark]

If you have a handler whose body contains say error "foo" all backends handle this differently and only rest-wai does the appropriate thing.

• rest-happstack doesn't print the error, the HTTP response is html saying "Something went wrong"
• rest-snap doesn't print the error, the HTTP response is text containing the error message
• rest-wai prints the error, the HTTP response is text saying "Something went wrong"

All backends should print the error, it may be less important that the response is the same, but showing the actual error message like rest-snap does is bad.

[hesselink]

Isn't this just how the backends handle exceptions by default?

[bergmark]

Probably, but I think we should change it. At the moment a lot of errors are lost when using rest-happstack.

[dpwiz]

Take a note that error messages can leak sensitive information...

[hesselink]

So this is an issue mostly with happstack, because it uses lazy bytestrings. That means that if there is an undefined or something in the computation that produces a response, you might lose the error, even if you have a top level exception handler around your code. rest inherits this limitation, since it also uses a lazy bytestring. So I think it's up to users to handle this, with a top level exception handler and optionally forcing the response body if you want to be sure you catch everything.

[bergmark]

Is there anything we can actually do about this in rest? It sounds to me that users just have to pick a backend that does this properly. We can probably close this.

[hesselink]

We could switch rest to use some kind of streaming abstraction (pipes, conduit, io-streams). Then I think wai and snap could handle this correctly. I'm not sure how much work this would be. A lot of it would just be choosing what to use and seeing how it impacts the whole framework, I guess.

[bergmark]

wai already does this well enough, and snap-1.0 should also fix it.

[hesselink]

OK, let's close it then.