On Mon, Jul 20, 2009 at 6:31 PM, Armin Ronacher<[email protected]> wrote: > > Hi, > > Drew Smathers wrote: >> Am I alone in this opinion? Armin and other werkzeug devs -- Is the >> current behavior born out of concern for preserving backwards >> compatibility or do you think the silencing the error is really the >> best behavior? If the latter, why? I'd appreciate any feedback. > First of all, thanks for the feedback. It's appreciated. > > The reason why the form parsing silently fails for multipart requests if > the incoming data is malformed has to main reasons. > > The first one is the most important one: form data parsing happens > implicitly when accessing the .form/.files/.stream attributes. And that > has a few implications: the kick for the parser can happen from pretty > much everywhere, including introspection tools. If you access a > property and the property raises anything else but an `AttributeError` a > lot of Python code breaks that depends on that behavior. The second > problem is that because of that there is no central place to catch those > errors. Now the last change in 0.5.1 made it possible to change that > behavior by doing two things: > > a) overriding Request.__init__ to force the data to be parsed by > accessing the .form attribute > b) overriding the _form_parsing_failed method to react to parse errors > properly. > > This of course means that form data is no longer lazy loaded. It means > whenever a request sends data it's parsed, even if there is not request > that would consume the data. > > Now the second reason why it's silent is compatibility. Compatibility > with other people depending on it when converting their code from > whatever it's coming from. And sometimes you have to make some radical > choices how to deal with malformed data. > > There is a great quote by someone I have forgotten that says "be > generous in what you receive but be strict in what you send". That's > one of the design principles Werkzeug follows by default. That covers > the following cases: > > - malformed incoming unicode (we pretty much ignore decoding errors) > - malformed form data (we silently ignore parsing errors) > - malformed cookie headers (we try to parse as many of them as possible > and skip broken cookies) > - malformed http headers in general (etags, if-match etc.) > > I hope that explains why it works that way by default. I know it > probably contradicts one of the python principles ("Errors should never > pass silently") but the web is a savage place and we have to cope with > it without causing frustration. Most people forget about error handling > very often and Werkzeug tries to solves as many of those problems as > possible by itself. > > There is another situation where Werkzeug does something for you, you > probably wouldn't expect unless you read the documentation carefully: > KeyErrors raised by some data structures are not only key errors but > also bad request errors. That means if you have catch-all for http > exceptions you would send back an 400 bad request on key errors caused > by missing form keys. > > Finally let me say that I'm welcome to add more hooks (by implementing > methods to override, more function arguments etc.) that allow the > behavior of Werkzeug to be fine tuned so that you can better adapt it to > what you want it to do. >
Thanks. These seem like compelling reasons for not having the app explode on form parsing errors; since a hook is provided to handle errors for applications where this is important, I'm happy. -Drew --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pocoo-libs" 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/pocoo-libs?hl=en -~----------~----~----~----~------~----~------~--~---
