i'm not sure if i like the idea of this. the 400 error is for bad/malformed syntax and the request can't be fulfilled.
in this situation, the http level request is most certainly understood and authorized -- the error is in the application logic and should be served on such -- not pushed into the http level. a non-browser, or browser, app can just expect a json packet as such: status: error / success success: more info error: detailed info or hash of info additional_fields and have all the information needed to intereact with pylons. i don't see how saying that a 'good request' is a bad request will make things easier. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
