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.
Regards,
Armin
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
