A minor change to how field names are encoded

[phatmaus]

I recently needed to use an API that couldn't handle the field names being
encoded with quotes. I added an optional parameter to FormData.append,
that can remove the quotes. Others in a similar situation might find it
useful and it can have no side effects on existing code as far as I can
see.

[alexindigo]

Thanks for your interest in the package.

Do you mind to elaborate on your use case? Seems like one-off from here, especially comparing with the number of changes.

And I see more changes than just described change.

PS. FormData meant to be "low-level" implementation, focused on sending data with the right headers and right encoding. Accommodating different users preferences (e.g. converting arrays to strings) is out of scope of this project.

[alexindigo]

Issue found: This function's cyclomatic complexity is too high. (9)

[Igorbek]

I would recommend to move this parameter to the options, since it may be passed here anyway.

[alexindigo]

+1, thanks

[phatmaus]

Hi Alex. Thanks for the quick response.

Is it the standard that the field names have to be surrounded by quotes? i.e. 'name="' + field + '"'
I ran into an API that cannot parse that and I figured that others may have run into a similar issue. And the module can still be used like before, since if you call .append( with 2 or 3 parameters, encodeFieldNamesWithoutQuotes? will just evaluate to false and the logic will be completely unchanged, ditto for other calls of _multiPartHeader(. It introduces a couple of lines of repetition and I did think of writing it as something like:
['form-data', 'name='+encodeFieldNamesWithoutQuotes?'"':'' + field + encodeFieldNamesWithoutQuotes?'"':'' ].concat(contentDisposition || []),
but I think that looks ugly.

[alexindigo]

Do you mind to clean up unnecessary changes like this?
And add tests for the use case?

Thank you.

[alexindigo]

@phatmaus Thanks for the details. Could you put details on the server/environment in the comments block in the new test file (and mention it in the readme). I think it would help others to find solution faster than just introducing verbose flag.

Thanks.

[danielgindi]

Based on the RFC https://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.5.1
There's no need for all of this. No options and such. You should always quote that field.

[Igorbek]

@danielgindi correct. but quoted-string must be escaped, not just accompanied by ". So the correct change would be to escape any such characters.

[danielgindi]

@Igorbek of course!

[ibdf]

This is old, I think it was never implemented, but I ran into this same issue - a third-party api that cannot parse the quotes.