HTTPoison multipart post

The boundary from HTTPoison meets the requirements of RFC2046 - it’s more than 1 and less than 70 characters from the specified character set. If the vendor’s parser is breaking on it, the vendor’s parser is broken.

These logs show that the vendor’s parser might be broken (there’s no data printed from the second one) but they offer no suggestion of what the problem is. The only thing that can tell us what’s going on is the raw bytes actually sent to the server.

One way to capture these is with netcat (frequently shortened to nc) - a handy utility program that will listen on a specified port and then print exactly what comes in when invoked with -l

For curl:

Matts-MacBook-Pro-2:~ mattjones$ nc -l localhost 8888
POST / HTTP/1.1
Host: localhost:8888
User-Agent: curl/7.54.0
Accept: */*
Authorization: Bearer asupersecrettokentoauthenticatewith
Content-Length: 619
Expect: 100-continue
Content-Type: multipart/form-data; boundary=------------------------58692fd24caf27b7

--------------------------58692fd24caf27b7
Content-Disposition: form-data; name="orgid"

1234567890987654321
--------------------------58692fd24caf27b7
Content-Disposition: form-data; name="from"

5555555555
--------------------------58692fd24caf27b7
Content-Disposition: form-data; name="to"

1234
--------------------------58692fd24caf27b7
Content-Disposition: form-data; name="file"; filename="helloworld.erl"
Content-Type: application/octet-stream

% hello world program
-module(helloworld).
-export([start/0]).

start() ->
    spawn(fun() -> ok end).
--------------------------58692fd24caf27b7--

Versus the result from HTTPoison:

Matts-MacBook-Pro-2:~ mattjones$ nc -l 127.0.0.1 8888
POST / HTTP/1.1
Authorization: Bearer asupersecrettokentoauthenticatewith
Host: 127.0.0.1:8888
User-Agent: hackney/1.18.1
Content-Type: multipart/form-data; boundary=---------------------------bydneyeiuypqrgyb
Content-Length: 834

-----------------------------bydneyeiuypqrgyb
content-length: 102
content-type: application/octet-stream
content-disposition: form-data; name="file"; filename="helloworld.erl"

% hello world program
-module(helloworld).
-export([start/0]).

start() ->
    spawn(fun() -> ok end).
-----------------------------bydneyeiuypqrgyb
content-length: 10
content-type: application/octet-stream
content-disposition: form-data; name="from"

5555555555
-----------------------------bydneyeiuypqrgyb
content-length: 4
content-type: application/octet-stream
content-disposition: form-data; name="to"

1234
-----------------------------bydneyeiuypqrgyb
content-length: 19
content-type: application/octet-stream
content-disposition: form-data; name="orgid"

1234567890987654321
-----------------------------bydneyeiuypqrgyb--

Notable differences:

• HTTPoison always sends Content-Length headers
• HTTPoison always sends Content-Type headers

You could try passing an explicit Content-Type to the form fields; there are bug reports that suggest that some servers don’t handle application/octet-stream fields correctly. For instance, pass {"from", from, [{"content-type", "text/plain"}]} instead of {"from", from}. Doing this locally has the desired effect (the content-type values change for the form fields).

On the other hand, apparently some servers don’t like Content-Length:

https://github.com/edgurgel/httpoison/issues/286