0

I am trying to use Apache Commons's HttpClient to send a multipart POST request with a binary file and a couple of string parameters.

However, it seems that somewhere along the line, some garbage text is making its way into my string parameters. For instance, as confirmed through the debugger, the sizeBody variable here is indeed holding the value "100":

StringBody sizeBody = new StringBody("100", Charset.forName("UTF-8"));

However, if I listen to the request with Wireshark, I see this:

--o2mm51iGsng9w0Pb-Guvf8XDwXgG7BPcupLnaa
Content-Disposition: form-data; name="x"
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

100
a5

--o2mm51iGsng9w0Pb-Guvf8XDwXgG7BPcupLnaa

Note the a5 after the 100.

What could be causing this? Where should I look?

pkaeding
  • 36,513
  • 30
  • 103
  • 141

2 Answers2

1

What you are seeing are likely to be chunk headers used by so the called chunk transfer encoding [1]. See if the message head has a Transfer-Encoding: chunked field.

[1] http://en.wikipedia.org/wiki/Chunked_transfer_encoding

ok2c
  • 26,450
  • 5
  • 63
  • 71
0

I had this same issue testing my POSTs with NanoHTTPD receiving them. It's indeed that HttpClient is using chunked transfer encoding, which NanoHTTPD doesn't support. It did that in my case because the binary file was supplied via an InputStreamBody, and since that cannot determine its own content length (it just sends back -1), the client uses chunked encoding.

I switched to using a ByteArrayBody for the file contents, and since that and StringBody can supply content lengths, the requests now do not use chunked encoding.

ByteArrayOutputStream baos = new ByteArrayOutputStream();
IOUtils.copy (fileInputStream, baos);  // from Apache Commons IO, or roll your own
ContentBody filePart = new ByteArrayBody (baos.toByteArray(), fileName);

Of course, if your file is huge, loading the whole thing into a byte array as above could cause memory problems.

bhavanki
  • 1,527
  • 10
  • 16