multipart/form-data does not comply with the RFC 1867 standard

[xljiulang]

this is the package of MultipartFormDataContent/MultipartContent

POST /webapi/user/UpdateWithMulitpart HTTP/1.1
Host: localhost:9999
Content-Type: multipart/form-data; boundary="456a4835-40c9-40c2-929e-502c01ff5562"

--456a4835-40c9-40c2-929e-502c01ff5562
Content-Disposition: form-data; name=Account

laojiu
--456a4835-40c9-40c2-929e-502c01ff5562--

but RFC 1867 like this

POST /webapi/user/UpdateWithMulitpart HTTP/1.1
Host: localhost:9999
Content-Type: multipart/form-data; boundary=456a4835-40c9-40c2-929e-502c01ff5562

--456a4835-40c9-40c2-929e-502c01ff5562
Content-Disposition: form-data; name="Account"

laojiu
--456a4835-40c9-40c2-929e-502c01ff5562--

[davidsh]

What part of the above is incorrect? Are you referring to places where the double-quotes around tokens is different, i.e.

Content-Type: multipart/form-data; boundary="456a4835-40c9-40c2-929e-502c01ff5562"

vs.

Content-Type: multipart/form-data; boundary=456a4835-40c9-40c2-929e-502c01ff5562

I believe the quotes are optional as long as the token doesn't have any white-space within.

Is there a server or application that is broken due to this perceived difference? Also, RFC 1867 is from 1995 and I think this RFC has been replaced by a newer one (I'm don't remember the new number though).

[xljiulang]

@davidsh
MultipartContent class use quote boundary, i found it also work normally on NodeJs http server, except the form-data not used quote name.

no quote boundary + quote form-data name，node js work normally

{
	fields: {
		Account: ['laojiu']
	},
	files: {
		Image: [
			[Object]
		]
	}
}

quote boundary + no quote form-data name，node js get null value of fieldName

{
	fields: {
		null: ['laojiu']
	},
	files: {
		null: [
			[Object]
		]
	}
}

[gabornemeth]

I have experienced problem with no quotes on form-data names when trying to use [this service].(http://developers.strava.com/docs/reference/#api-Uploads-createUpload)
It definitely does not recognize parameters without quotes. I had a hard time to figure out this is the problem (comparing with Postman's request).
Although workaround that works for me is to manually apply "" around the parameter name in MultipartFormDataContent.Add.

[karelz]

Can you post minimal repro we could run locally?

[gabornemeth]

Here is a repro. MultipartRepro.zip
A proper access token has to be provided for this request. I can give you one, just ping me in private (my e-mail is public).

[karelz]

@Caesar1995 can you please take a look?

[caesar-chen]

According to RFC7578:

The Content-Disposition
header field MUST also contain an additional parameter of "name"; the
value of the "name" parameter is the original field name from the
form (possibly encoded; see Section 5.1).

If the original field name from the form is "Account" (includes the quote), for example, then "\"Account\"" should be passed in to MultipartFormDataContent.Add.

The only place where .NET layer should explicitly add quotes is around boundary parameter values (as suggested in below RFCs). We do the exact same thing on Framework as well.
https://tools.ietf.org/html/rfc2046#section-5.1.1
https://tools.ietf.org/html/rfc7578#section-4.2

cc: @davidsh

[jeffvandyke]

@caesar-chen, As a cautionary note, the situation may be different for HTTP headers and email headers, that last document is titled "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", and neither of the linked RFCs mention HTTP headers.

Checking MDN's page on Content-Type links to 2 RFC specs for HTTP headers (first link here), that doesn't say that quoting the boundary in the spec is OK, and uses unquoted boundary specifications in its valid example, and further acknowledges that "Although [RFC2046] permits the boundary string to be quoted, some existing implementations handle a quoted boundary string incorrectly."

We actually ran into this issue using .NET Core to send a multi-part post with a file to an embedded http server. The POST worked with curl, an html form, a JavaScript Ajax post with FormData, but failed with .NET Core.

In summary, .NET Core's posting method is breaking more implementations than the browser's and curl's way of posting files.