3
votes

According to the HTML specs:

If the contents of a file are submitted with a form, the file input should be identified by the appropriate content type (e.g., "application/octet-stream"). If multiple files are to be returned as the result of a single form entry, they should be returned as "multipart/mixed" embedded within the "multipart/form-data".

I tried a simple HTML form with <input type="file" name="files" multiple> but when selecting multiple files in Chrome or Firefox, the serialized form simply has a regular MIME part for each file and no "multipart/mixed" part.

Are there web browsers that upload files using "multipart/mixed" inside "multipart/form-data" or was this part of the spec never implemented in practice?

Update 1: I tested the following browsers:

  • Chrome 34
  • Firefox 28
  • Safari 7.0.3
  • IE 11
  • Opera 20

Update 2: I also tried with curl curl -i -F secret=42 -F [email protected] -F [email protected] http://localhost:8080/ but it behaves the same as the browsers.

1

1 Answers

0
votes

I was needing to know the same thing, so just for anyone else who comes across this.

According to the whatwg standard, forms using multipart/form-data should be encoded using RFC 7578:

Encode the (now mutated) form data set using the rules described by RFC 7578, Returning Values from Forms: multipart/form-data, and return the resulting byte stream.

Taking a look at RFC 7578 we find this:

4.3. Multiple Files for One Form Field

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.