The code for implementing RFC1867 with a file upload (in rfc1867.c) expects headers to be in the order:

--Boundary...........
Content-Disposition: attachment; name="userfile"; filename="boot.ini"
Content-Type: application/octet-stream;

file data.....
--Boundary...........

However, RFC1867 does not enforce this ordering. Some clients generate the Content-Type header prior to the Content-Disposition header which causes the file upload to fail, without any error message being generated.

I discovered this using a set up components from Dev-Soft (www.dev-soft.com) in Borland's Delphi. Their MIME component generates the multi-part form data for a file with Content-Type before the Content-Disposition. After beating my head against the wall for a few hours I finally figured out where the problem was. Fortunatly I was able to circumvent their ordering, although it made my code pretty kludgy.