Enforcing a max size for form field values read into memory (review/determination of next steps needed)

Hi, I think I will be able to make good on my promise to give all the tickets that were in the review queue on last Friday a review for 1.9, except for this one... https://code.djangoproject.com/ticket/21231 https://github.com/django/django/pull/3852 Mostly I am wondering if there any other fra

Re: Enforcing a max size for form field values read into memory (review/determination of next steps needed)

This was deferred from 1.9 as it was still under review around the alpha deadline. I've updated the patch to merge cleanly and am asking for anyone interested in reviewing it to do so in the next month (ideally well before the May 16 alpha release date) so we can get it into 1.10. Thanks! https

Re: Enforcing a max size for form field values read into memory (review/determination of next steps needed)

I have a small concern. The two new settings looks like will work on uploaded files count (multipart encoding types) and number of fields sent (url encoded encoding). What happens to other request types such as JSON, XML, plain text etc... If you are using django-rest-framework, how would the f

Re: Enforcing a max size for form field values read into memory (review/determination of next steps needed)

My understanding is that Django doesn't do any parsing of JSON, XML, etc but rather simply makes such content available as a raw bystring, request.body. Therefore I don't see how Django could offer protection for the cases you mentioned. On Friday, April 15, 2016 at 6:43:27 PM UTC-4, Cristiano

Re: Enforcing a max size for form field values read into memory (review/determination of next steps needed)

> If you are using django-rest-framework, how would the fields counter work?. It would be a shame if only multi part and urlencoded uploads would have the benefit of these checks, while still allowing json, xml and others still be "exploited". Note I didn't really read the code changes completel

Re: Enforcing a max size for form field values read into memory (review/determination of next steps needed)

Hi, In particular I'm interested in this new setting: DATA_UPLOAD_MAX_MEMORY_SIZE [1] that only seems to be checked against mutlparts [2] and url encoded[3] request bodies. It could be good that this setting is also checked against other types where request.body is read directly, as you can st

Re: Enforcing a max size for form field values read into memory (review/determination of next steps needed)

As noted in the ticket, PHP has built in limit in its config http://stackoverflow.com/questions/2364840/what-is-the-size-limit-of-a-post-request Apache can limit it "LimitRequestBody 1048576" http://modwsgi.readthedocs.org/en/develop/user-guides/configuration-guidelines.html#limiting-request

Re: Enforcing a max size for form field values read into memory (review/determination of next steps needed)

It seems there was request.body checking in previous iterations of the PR but it was dropped for reasons that aren't entirely clear to me: https://github.com/django/django/pull/3852#discussion_r35350372 On Wednesday, April 20, 2016 at 9:30:48 PM UTC-4, Cristiano Coelho wrote: > > Hi, > > In parti

Re: Enforcing a max size for form field values read into memory (review/determination of next steps needed)

After discussion on the PR, we concluded that the reasons that the request.body check was removed weren't valid, so this check is reinstated. I believe I've addressed all Tom Christie's concerns by now. If anyone else would like to take a look, now is the time. Thanks! https://github.com/django

Re: Enforcing a max size for form field values read into memory (review/determination of next steps needed)

A new ticket asks how to elegantly handle this in the admin actions where it's easy to post more than 1000 values using the "select all" button. My feeling is that applications shouldn't change their behavior based on this setting, but a consensus on how to proceed here might be useful for docu

Re: Enforcing a max size for form field values read into memory (review/determination of next steps needed)

> a consensus on how to proceed here might be useful for documenting best practices as other apps run into similar troubles. I guess I'd suggest... Most realistic in immediate future: Accept it as a current limitation (possibly handle TooManyFieldsSent) Someday later, perhaps: Allow a "select e