I spent a whole day trying to figure out how to use http components to send a file from a java program mimicking a POST multipart/form-data form.

The problem was that while a common HTML form worked with no problems at all, the POST generated with http commons was always rejected by the server.

So, I decided to dump the HTTP requests sent by the browser and by http components, and here’s what I got.

Request generated from the browser

------WebKitFormBoundaryYuxYFZoJg4fx2Tfu

Content-Disposition: form-data; name="filename"; filename="index.idx"
Content-Type: application/octet-stream
[file content]

------WebKitFormBoundaryYuxYFZoJg4fx2Tfu--

Request generated from http commons

--xFwQ1jzWbqQIKivTUrK68BurHld66kpMCz3Fv9P

Content-Disposition: form-data; name="filename"; filename="index.idx"
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
[file content]

--xFwQ1jzWbqQIKivTUrK68BurHld66kpMCz3Fv9P--

As you can see there’s a “Content-Transfer-Encoding: binary” header that is the one that caused the problem in the server. After a while I discover than when you create a new MultipartEntity, you can optionally specify a mode of operation. Currently supported modes are HttpMultipartMode.STRICT and HttpMultipartMode.BROWSER_COMPATIBLE. It’s not worth to mention that the default mode in STRICT, that maybe does not work with old or not fully standard web servers. If BROWSER_COMPATIBLE is specified instead, the data sent by http commons does not contain any Content-Transfer-Encoding header, and the delivery of the file terminates successfully.

Here’s the piece of code:

MultipartEntity reqEntity = new MultipartEntity(HttpMultipartMode.BROWSER_COMPATIBLE);