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
The form data for a form field might include multiple files.
[RFC2388] suggested that multiple files for a single form field be transmitted using a nested "multipart/mixed" part. This usage is deprecated.
To match widely deployed implementations, multiple files MUST be sent by supplying each file in a separate part but all with the same "name" parameter.
Receiving applications intended for wide applicability (e.g., multipart/form-data parsing libraries) SHOULD also support the older method of supplying multiple files.
and this practice is unsurprisingly common, and I am facing the exact same case.
The issue
The name field does not have to be unique. There are few common cases when a duplicated name field is required (e.g., when uploading an array of files), and this case should be properly covered.
First of all, thanks for the wonderful project!
colly
has saved our team a lot of time!!Context
ref: #8, #33
According to RFC7578 section 4.3:
and this practice is unsurprisingly common, and I am facing the exact same case.
The issue
The
name
field does not have to be unique. There are few common cases when a duplicatedname
field is required (e.g., when uploading an array of files), and this case should be properly covered.colly/colly.go
Lines 551 to 559 in 99b7fb1
colly/colly.go
Lines 1461 to 1469 in 99b7fb1
Unfortunately, the current implementaion accepts
map[string][]byte
, which enforcesname
to be unique.Suggestion
Maybe we can accept
[]Subpart
so that:filename
and other metadata can be optionally includedname
fields are allowedand so on.
I would love to hear your opinion! If you think this is feasible, I will start working on it.
The text was updated successfully, but these errors were encountered: