Hi Conor, This is NOT a known issue, and very strange on top of that. If you could create a patch against "test_postprocessor" that reproduces the specific problem, that would definitively be appreciated and would speed up my investigation...
Happy hacking! Christian On 5/13/20 3:50 PM, Conor Lennon via libmicrohttpd wrote: > I'm having an issue with multi-part data in libmicrohttpd > > When the following HTTP request is sent > > > POST /api/csvrestore HTTP/1.1 > Host: 127.0.0.1 > Authorization: Basic XXXXXXXXXXXXXXXXXXXX > User-Agent: PycURL/7.43.0 libcurl/7.43.0 NSS/3.19.1 Basic ECC > zlib/1.2.7 libidn/1.28 libssh2/1.8.0 > Accept: */* > Content-Type: multipart/form-data; > boundary=----------ThIs_Is_ThE_bOuNdArY_$-- > Expect: 100-continue > Content-Length: 22718 > > ------------ThIs_Is_ThE_bOuNdArY_$-- > Content-Disposition: form-data; name="csvfile"; filename="csvconfig.csv" > Content-Type: text/csv > > MY DATA > > what libmicrohttpd is passing up to my application is > > > ------------ThIs_Is_ThE_bOuNdArY_$-- > Content-Disposition: form-data; name="csvfile"; filename="csvconfig.csv" > Content-Type: text/csv > > MY DATA > > > However, when the following HTTP request is sent > > POST /api/csvrestore HTTP/1.1 > Host: 172.28.2.220 > Authorization: Basic XXXXXXXXXXXXXXXXXXXX > User-Agent: curl/7.58.0 > Accept: */* > Content-Length: 22743 > Content-Type: multipart/form-data; > boundary=------------------------8ab9ddd6a63717a0 > Expect: 100-continue > > --------------------------8ab9ddd6a63717a0 > Content-Disposition: form-data; name="csvfile"; filename="system.csv" > Content-Type: application/octet-stream > > MY DATA > > I correctly just get "MY DATA" passed up to me by libmicrohttpd. > > Is this a known issue, or should I prepare sample code that demonstrates > what I have? > > I presume the difference that is causing the issue is that when the > content-length is after the content-type, there is a problem. > > Regards, > > Conor >
signature.asc
Description: OpenPGP digital signature
