Content-Type not sent unless a filename is set about form-data HOT 18 CLOSED

I'm not sure I fully understand the problem. Can you elaborate on the issue? Thank you.

from form-data.

formData.append('file', pngBuf, { contentType: 'image/png' }); // Results in no Content-Type header being sent
formData.append('file', pngBuf, { filename: 'image.png', contentType: 'image/png' }); // Results in filename and Content-Type header being sent

from form-data.

When you upload file to the server usually it's expected to have a filename, is there a use case, where you what to omit the filename?

from form-data.

In this case I was simply uploading a buffer containing PNG data. Since it doesn't have a filename, I expected to be able to omit it.

from form-data.

For me it's reasonable to expect to have both custom mime-type and filename, since it's the way usually servers expect data to come in, unless I'm missing something.

from form-data.

If both are required for them to work, can there be some documentation of this?

from form-data.

I think filename is part of the "convention" that makes servers to work correctly.

What kind of wording you'd like to see in the documentation?

from form-data.

A simple note indicating that contentType does nothing on its own would have saved me the dive into the code.

from form-data.

I see, I'll try to come up with explanation. Content-type doesn't do nothing, it sets custom content type, although it affects only file-like object (has path or custom filename).

from form-data.

I was thinking, and your proposal does make sense. Although I'd like to have it for new minor version, it feel to close to breaking current API. Along with default mime-type for buffers.

from form-data.

Being able to optionally set the Content-Type for each part would be very handy.
An example use case is when you send JSON in one part. For now it is parsed as text/plain and it would be better set Content-Type to application/json.
Example issue: Flolagale/mailin#5

from form-data.

@alexindigo If filename field is required, the current version must throw an error if only contentType is set instead of silently failing (would save me 2h today)
As for the use cases for it - there's plenty of APIs that ignore filenames but accept a content type. I don't have a problem with sending spam as filename, but form-data needs to tell me I have to. And seeing as you didn't implement it to throw, I guess it's ok to send just the contentType anyway.

from form-data.

👍 for being able to set Content-Type to application/json.

from form-data.

Alex - don't agree, when you send a json as one part, which should be processed by the server, you just want to set a name, but not a filename, as it will be parsed but not saved anywhere.

from form-data.

👎 for "content-type" of "application/json". "multipart/form-data" should work just fine for this case? Also this would deviate from the browser spec.

from form-data.

Completely disregard my previous comment, I was thinking the content-type header for the entire request.

This should be an easy fix. Will create a PR tomorrow.

from form-data.

Thanks to @DylanPiercey it's going out with 1.0.0-rc3.

from form-data.

Fixed in #138

from form-data.