request.form and 400 Bad Request

request.form and 400 Bad Request

From:

Jon Ribbens

Date:

2014-08-31 @ 16:58

I kind've get why request.form is sending a 400 Bad Request response
when the key is unknown. What I don't get at all is why this behaviour
continues when Flask is running in debug mode.
It means that if you have a typo in your HTML or your code such that
there is a field name mismatch, you get no assistance at all in
working out where it happened, you have to completely guess. Rather
than any other type of typo where you would get the lovely traceback
with the interactive console.
So could Flask please be changed so that *in debug mode* the unknown
key is treated as a normal exception resulting in a traceback?

Re: [flask] request.form and 400 Bad Request

From:

Daniel Neuhäuser

Date:

2014-08-31 @ 17:45

There is an issue tracker, use it.
> So could Flask please be changed so that *in debug mode* the unknown> key is treated as a normal exception resulting in a traceback?
+1 on the exception
-1 on in debug mode, let's do it always
This breaks backwards compatibility, so if we do so let's make it worth it.

Re: [flask] request.form and 400 Bad Request

From:

Jon Ribbens

Date:

2014-08-31 @ 20:58

On Sun, Aug 31, 2014 at 07:45:14PM +0200, Daniel Neuhäuser wrote:
> There is an issue tracker, use it. > > > So could Flask please be changed so that *in debug mode* the unknown> > key is treated as a normal exception resulting in a traceback?> > +1 on the exception> -1 on in debug mode, let's do it always> > This breaks backwards compatibility, so if we do so let's make it worth it.
Removing the special-casing in production mode just changes the
response code from 400 to 500, I'm not sure why you would want that.
Removing it in debug mode changes the response from "useless
boilerplate" to "useful debugging info", so the utilitiy is clear.
Plus, changes that only affect debug mode cannot break backwards
compatibility since anyone running production code in debug mode has
bigger problems already.