-
Notifications
You must be signed in to change notification settings - Fork 23
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
Added support for multiple filenames with same part name #28
Added support for multiple filenames with same part name #28
Conversation
@nikolaydubina, one question: does this work for all fields or just file fields? It would be best if it works for all, as there is nothing special in my opinion with files. |
Since it relies on "filename" for key, this would work only for files. It seems that "name" is supposed to be unique in form data RFC2388. And widely used format for multiple files is to have same "name" 4.3 RFC7578, with filename could be omitted sometimes 4.2 RFC7578. In later case, this code would not work. Moreover, case when "filename" and "name" are the same but content is different is also easy to imagine. Perhaps a better way would be to add counter to part key instead of filename. This would be more generic and solve issues above. I will update PR. |
Hi @bungle, I have updated the PR to handle case you described and fixed few edge cases. |
ping @bungle |
Hi @subnetmarco @bungle, I appreciate if you guys review and hopefully merge this fix, in that case we would not need to maintain our fork of this repo. |
@nikolaydubina, I try to get it in next few days. |
@nikolaydubina can you give example of how user uses this addition to read multiple values if the field is posted multiple times with same name? I see tests that use something called internal etc., but how does this look on public facing api, like |
I see, thanks! While the suffix local files = m:get_as_array("files")
print(files[1].value)
print(files[2].value)
local single = m:get_as_array("single")
print(single[1].value) and local data = m:get_all_with_arrays()
print(data.files[1])
print(data.files[2])
print(data.single) Or something like that? |
@nikolaydubina what do you think about the ^ |
Hi, if it was only up to me, I void keep original version. However, since you guys maintain Kong you may know better and take precautions. API you suggested sounds reasonable, I will update PR. One clarification, fields that repeat will not be present in :get and :get_all right? |
Fields that repeat should stay the same as before (with |
The:
Woud effectively be the same as: (but for multipart/form-data input) When it comes to multiple values (e.g. same name multiple times -> lua array, otherwise string) |
@nikolaydubina, I think if you could make those changes, we could merge this. I will then prepare a new release. Thank you! Let me know if there are issues with my proposal. |
Thanks for checking on this! Will update PR sometime this week. Was sidetracked by other projects. |
Hello @bungle, I have updated PR. Now it does not have "_part_number" anymore. All parts have array (table) of indexes. I also added two API changes you requested:
A couple of methods like Updates tests. Added test case for new functions. Added whitebox test asserts for indexes. |
Perhaps we need two then:
and
Where Right now we don't have equivalent for that, and it would be |
Yes this is better. Added this API and test case. |
Problem
It is not uncommon to attach multiple files at once to the same multipart field. In particular, we found this issue at @fundingasiagroup in one of our plugins. When multiple files are attached in request to the same part name, behavior is unstable. For example in this scenario,
This is happening because "data" structure holds all data, yet "indexes" structure overwrites indexes for files since they share part name.
Fix
If name of part repeats, append
_part_number_
with number of part to the name in "indexes" structure.Compatibility
Test plan
More examples
Here is HTTP output of how Postman would encode it: