When parsing a multi-part POST, retain original pairs #2088
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The input is not guaranteed to be rewindable, and the default parameter expansion loses details of the parameter names.
For form-encoded data, we (already) retain the full string: it contains only simple key/value pairs, and will be of a manageable size.
Multipart data may contain uploaded files, so we don't wish to retain the full input string -- that's why we dropped the rewindability requirement on the input stream. Instead, we retain an array of two-element arrays representing the "raw" key-value pairs as we parsed the stream. This minimizes additional memory use, because the values are the same objects we use in the params hash, while still allowing an interested consumer to apply their own logic to parameter name interpretation.
@jeremyevans @ioquatix I believe this is the minimal version of what we discussed at Kaigi. Apologies for the delay.
For a consumer to use it in this state, they'd need to call
Rack::Request#POST
, relying on its side-effect, then manually pullrack.request.form_pairs
. Neither of those steps feels like a great API, so I think it would make sense to provide abody_param_list
-like method as in #2038, but it might be easier to discuss that in a separate follow-up PR, if this seems independently reasonable as the direct implementation / extra retained values?