Doubling the backslashes seems like a bug to me

Agreed. @monnerat can you recall the reason behind this? The code that does this seems to be here

I could reproduce the problem by adjusting tests/libcurl/lib554.c like this:

diff --git a/tests/libtest/lib554.c b/tests/libtest/lib554.c
index cc21d245b..79ab72136 100644
--- a/tests/libtest/lib554.c
+++ b/tests/libtest/lib554.c
@@ -80,11 +80,11 @@ static int once(char *URL, bool oldstyle)
 
   /* Fill in the file upload field */
   if(oldstyle) {
     formrc = curl_formadd(&formpost,
                           &lastptr,
-                          CURLFORM_COPYNAME, "sendfile",
+                          CURLFORM_COPYNAME, "send\\file",
                           CURLFORM_STREAM, &pooh,
                           CURLFORM_CONTENTSLENGTH, (long)pooh.sizeleft,
                           CURLFORM_FILENAME, "postit2.c",
                           CURLFORM_END);
   }

Given some more thoughts: I suppose this treatment is done to "escape" the letter correctly then generating the header so that a MIME compliant receiver would un-escape it correctly in the other end.

My server is a basic ASP.NET Core one and when I end up trying to extract the Request.Form.File[0].Name it is failing to "de-escape" that doubled backslash.

Visual Studio screenshot

I don't find a clear specifications of what should be the content-disposition encoding (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition), but if libcurl way of encoding the backslash is correct, I guess I should notify the ASP.NET Core. Does anyone know for sure how such a character should be encoded in that case?

Thank you,
David.

can you recall the reason behind this?

RFC 7578 (multipart/form-data) introduces the name parameter without specific additional BNF, thus it falls to be a generic Content-Disposition parameter.

RFC 2183 (content disposition) defines filename-parm := "filename" "=" value and refers to RFC 2045 for the value and parameter syntaxes.

RFC 2045 (MIME) defines parameter := attribute "=" value and value := token / quoted-string. It widely refers to RFC 822 for everything it does not define itself explicitly.

RFC 822 (Mail) defines quoted-string as:

     qtext       =  <any CHAR excepting <">,     ; => may be folded
                     "\" & CR, and including
                     linear-white-space>
     quoted-pair =  "\" CHAR                     ; may quote any char
     quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
                                                 ;   quoted chars.

Thus " and \ must be escaped with \ in name= and filename= values of the Content-Disposition header.

IMO, the escaping done by curl is correct and a receiving server should conform to this too.

@monnerat Thanks a lot, I was struggling to find this information. Then I guess I should notify the ASP.NET Core team. In the meantime, as a work around, I will be using another form text parameter to pass my information un-escaped.

@bagder Can we admit this is not a bug and add a note in the curl_formadd documentation?

Yes!