Should filename be treated as optional in Multipart requests

[colin-lamed]

We regularly see requests with file dispositions without filenames.

We have not identified exactly what is creating requests like this, but the specification for multipart/form-data says

 For form data that represents the content of a file, a name for the
 file SHOULD be supplied as well, by using a "filename" parameter of
 the Content-Disposition header field.  The file name isn't mandatory
 for cases where the file name isn't available or is meaningless or
 private; this might result, for example, when selection or drag-and-
 drop is used or when the form data content is streamed directly from
 a device.

However, the multipart parser in playframework will treat a file disposition without a filename as a regular data part.

It's a bit awkward to have to work with dataParts as well as fileParts. But probably a more important implication of this, is that the whole file content is loaded into memory, and files that exceed the play.http.parser.maxMemoryBuffer setting are rejected with a 413 (rather writing to disk and accepting up to the play.http.parser.maxDiskBuffer).

I wonder if the filename should be optional on the FilePart and all file dispositions should be treated as FileParts.

[mkurz]

Looking at the code, I am thinking about, is it even ok, regarding to the specs, to allow filename with form-data?
Because if we would just remove form-data here and make filename optional in the same code that handles (now only) file the problem would solve itself (and we would not need to change much and can keep datapart and filepart).

[colin-lamed]

Actually, it's probably not possible to do anything about this.

I only see that form-data is a valid disposition type in the spec for multipart/form-data.

And without filename, there's nothing to distinguish between a file part and a non-file part.

In theory, it may be possible to check the Content-Types of the parts - e.g. treat application/octet-stream as a file.

But this won't help with the cases we've seen where obviously binary data is provided without a filename, but also without a Content-Type - which I understand from the spec should default to text/plain.

I think for our use-case we may need a custom MultipartFormData parser which distinguishes between in-memory and file parts by content-disposition name (which is effectively the behaviour we see when uploading files to AWS S3 with multi-part)