You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
That means forms having about 128 widgets (give or take empty-markers and hidden controls) get silently cut at the 128 limit. Good or not submit buttons are usually last so processing does not even get to the button action.
processInputs calls multipart.parse_form_data with strict=False and without part_limit.
I might see a reason behind setting a default part_limit=128 and ignoring parse errors, but not sure whether that's something good or not.
The text was updated successfully, but these errors were encountered:
A short term solution would be to pass a higher part_limit to parse_form_data() and maybe re-evaluate the other limits too. In the meantime I'll work on multipart to have better documentation for those limits, and add a way to receive errors from parse_form_data() even in non-strict mode.
multipart
commit defnull/multipart@aa9b820 adds a limit on parsed parts of 128multipart 1.1.0 definitely has this
That means forms having about 128 widgets (give or take empty-markers and hidden controls) get silently cut at the 128 limit. Good or not submit buttons are usually last so processing does not even get to the button action.
processInputs
callsmultipart.parse_form_data
withstrict=False
and withoutpart_limit
.I might see a reason behind setting a default
part_limit=128
and ignoring parse errors, but not sure whether that's something good or not.The text was updated successfully, but these errors were encountered: