Add handling for multipart/mixed #2

New issue

Closed

opened 2015-06-11 12:39:50 +12:00 by mikedilger · 2 comments

mikedilger commented

2015-06-11 12:39:50 +12:00

(Migrated from github.com)

This is where a single multipart section is itself a multipart section. This happens when a file input field is filled with multiple uploaded files.

SkylerLipthay commented

2015-07-03 00:06:49 +12:00

(Migrated from github.com)

It's worth noting that this style is not seen in modern browsers, but I believe it should still be supported.

I'm not finding concrete specs for multipart/mixed. Is it historically only used to specify a named array of files? Or can you mix and match files and inline text content? Is it valid to infinitely nest multipart/mixed parts? Once I know what this library should support, I can implement this feature.

It's worth noting that this style is [not seen in modern browsers](http://stackoverflow.com/questions/23283099/are-there-web-browsers-that-upload-files-using-multipart-mixed-inside-multipa), but I believe it should still be supported. I'm not finding concrete specs for multipart/mixed. Is it historically only used to specify a named array of files? Or can you mix and match files and inline text content? Is it valid to infinitely nest multipart/mixed parts? Once I know what this library should support, I can implement this feature.

mikedilger commented

2015-07-03 08:42:50 +12:00

(Migrated from github.com)

Interesting. Since it's not seen in modern browsers, I will mark this P-Low. Still useful just in case.

multipart/mixed is defined in RFC 1341 section 7.2. It parses very much the same as multipart/form-data parsed, so significant sharing of code would be expected.

The top level multipart/form-data section would specify in its Content-Disposition header the input name of the file input, so all the parts of any multipart/mixed should be considered as files submitted under that form input. ~~Each one should offer a Content-Disposition header itself with a filename parameter, and if not, we may need some algorithm to make up filenames like "userfile1"..."userfileN" or whatever.~~ (edited: just leave filename: None)

I personally wouldn't bother coding for the case of recursive descent, but you can if you like, I wouldn't consider it wrong.

Interesting. Since it's not seen in modern browsers, I will mark this P-Low. Still useful just in case. `multipart/mixed` is defined in RFC 1341 section 7.2. It parses very much the same as multipart/form-data parsed, so significant sharing of code would be expected. The top level `multipart/form-data` section would specify in its `Content-Disposition` header the input name of the file input, so all the parts of any `multipart/mixed` should be considered as files submitted under that form input. ~~Each one should offer a `Content-Disposition` header itself with a `filename` parameter, and if not, we may need some algorithm to make up filenames like "userfile1"..."userfileN" or whatever.~~ (edited: just leave filename: None) I personally wouldn't bother coding for the case of recursive descent, but you can if you like, I wouldn't consider it wrong.

This discussion has been locked. Commenting is limited to contributors.