Better multipart support

[pluma]

I'd love to use this library to generate other content-dispositions headers in multipart messages. One of the use cases is form-data, where the individual fields have a content-disposition of form-data; name=fieldNameGoesHere.

This module has no problem parsing that, but it blows up when you try to generate a header without a filename.

To maintain backwards-compatibility as much as possible, I'd suggest making the filename argument optional if an options argument is provided instead, i.e.:

contentDisposition({type: 'form-data', {parameters: name: 'fieldNameGoesHere'}})

(Side note: I'd love to have the API actually be type, parameters rather than filename, options, but that would not only break backwards-compatibility, it'd also make the module less convenient for its original purpose (i.e. generating content-disposition headers for file attachments). I can only imagine this as a major version update with the old API as an additional method.)

[dougwilson]

So, I don't mind bumping the major (and in fact, it's not 1.0.0 yet since I haven't decided if I like the API).

In addition, one weird quirk is that the Content-Disposition header in HTTP vs multipart is actually slightly different, especially when it comes to the filename parameter and how it's contents are encoded (lame).

What do you think the API should look like to divide the two CD headers? I was originally thinking of like adding a {quirks: 'multipart'} option, but IDK if that's the best way to do it, either. Thoughts?

[dougwilson]

Semi-related: pillarjs/multiparty#101

[kognise]

Any updates on this?