New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Only count files (not all form elements) against the Multipart File Limit #814
Only count files (not all form elements) against the Multipart File Limit #814
Conversation
Has anybody looked at this? It seems like quite the bug to count all fields as files when parsing multipart requests. |
Hesitant to pull this in because I know the limit is to do with a security issue. I'm not sure where the file handles are actually created, so I don't know if this is an OK change to make. @spastorino can you take a look? Seems like you signed off on b0b5fb9 |
Can you squash your commits? |
large form with only one file, you can quickly hit the MultipartPartLimitError Add test for not hitting the multipart limit
3611741
to
7331561
Compare
squashed |
…t_for_fileparts Only count files (not all form elements) against the Multipart File Limit
We're running into this issue as well. Any thoughts on when 1.6.1 will be released? |
This fixes a bug where all form fields in a request are counted against the multipart file limit: rack/rack#814 This is an issue in production - some publications and organisations have a large number of dynamically added nested forms. When the form is submitted, a 500 is returned because the number of fields exceeds the limit. It only affects forms posted with multipart, e.g. ones that contain file fields. Zendesk: https://govuk.zendesk.com/agent/tickets/1037587 Story: https://www.pivotaltracker.com/story/show/94668330
This fixes a bug where all form fields in a request are counted against the multipart file limit: rack/rack#814 This is an issue in production - some publications and organisations have a large number of dynamically added nested forms. When the form is submitted, a 500 is returned because the number of fields exceeds the limit. It only affects forms posted with multipart, e.g. ones that contain file fields. Zendesk: https://govuk.zendesk.com/agent/tickets/1037587 Story: https://www.pivotaltracker.com/story/show/94668330
The fix seems to be in master, but not in version 1.6.1. When is next version expected? |
Could you backport this to 1.5 and release? |
…t_for_fileparts Only count files (not all form elements) against the Multipart File Limit Conflicts: lib/rack/multipart/parser.rb
…t_for_fileparts Only count files (not all form elements) against the Multipart File Limit Conflicts: lib/rack/multipart/parser.rb
…t_for_fileparts Only count files (not all form elements) against the Multipart File Limit
We have just hit this issue when Nginx (with Passenger) started erroring with a
Turning on debug log level pointed to the Rack::Multipart::MultipartLimitError, which was announced recently as a security release for 1.5.4 We could workaround by setting the RACK_MULTIPART_PART_LIMIT env var for now, but it would be nice to release a proper fix for this which doesn't count non-files towards the limit ? EDIT: 👍 |
Thanks for resolving this issue and releasing new versions so promptly! @johnnaegle @tenderlove @spastorino ❤️ |
I'm also getting a "Too many open files - Maximum file multiparts in content reached" error. I'm using rails's So there are multiple input fields on one page, but even if none of them is beeing changed (an image uploaded) I still get the error. Any ideas on how to fix that? |
We were getting "Too many open files - Maximum file multiparts in content reached". However, our form only had one file input. It had several hundred other form elements. Each was counted as a file.
Only increment the opened_files counter for file inputs. If you have a large form, you can quickly hit the MultipartPartLimitError, even though you aren't actually opening files