#1333 POSTing multiple files produces an invalid Content-Type line

closed-fixed
None
5
2015-02-17
2014-02-06
Rob Davies
No

Running:

curl --noproxy '*' -F"upload=@/tmp/t1,/tmp/t2" 'http://localhost:8080/test'

sends this:

POST /test HTTP/1.1
User-Agent: curl/7.35.0
Host: localhost:8080
Accept: */*
Content-Length: 545
Expect: 100-continue
Content-Type: multipart/form-data; boundary=------------------------ac8fa3db5d68f39f

--------------------------ac8fa3db5d68f39f
Content-Disposition: form-data; name="upload"
Content-Type: multipart/mixed, boundary=------------------------0d5bb0db572656a0

--------------------------0d5bb0db572656a0
Content-Disposition: attachment; filename="t1"
Content-Type: application/octet-stream

t1

--------------------------0d5bb0db572656a0
Content-Disposition: attachment; filename="t2"
Content-Type: application/octet-stream

t2

--------------------------0d5bb0db572656a0--
--------------------------ac8fa3db5d68f39f--

RFC2616 and RFC2045 state that the comma after "Content-Type: multipart/mixed" should be a semicolon.

The following patch fixes the issue:

diff -Naur curl-7.35.0/lib/formdata.c curl-7.35.0.fix/lib/formdata.c
--- curl-7.35.0/lib/formdata.c  2014-01-05 22:07:54.000000000 +0000
+++ curl-7.35.0.fix/lib/formdata.c  2014-02-05 09:28:22.443251990 +0000
@@ -1227,7 +1227,7 @@
       }

       result = AddFormDataf(&form, &size,
-                            "\r\nContent-Type: multipart/mixed,"
+                            "\r\nContent-Type: multipart/mixed;"
                             " boundary=%s\r\n",
                             fileboundary);
       if(result)

Version info:
curl -V
curl 7.35.0 (x86_64-unknown-linux-gnu) libcurl/7.35.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smtp smtps telnet tftp
Features: IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP

Thanks,

Rob.

Discussion

  • Daniel Stenberg

    Daniel Stenberg - 2014-02-06
    • status: open --> open-confirmed
    • assigned_to: Daniel Stenberg
     
  • Daniel Stenberg

    Daniel Stenberg - 2014-02-06

    I agree with you that it looks wrong and it should rather use a consistent behavior.

    I'm quite sure this comma originates from (my reading of) RFC1867 since the examples in section 6 there have exactly this flaw...

     
  • Daniel Stenberg

    Daniel Stenberg - 2014-02-08
    • status: open-confirmed --> closed-fixed
     
  • Daniel Stenberg

    Daniel Stenberg - 2014-02-08

    Thanks, fixed in commit 9597f7dfbc95564b0c

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks