I don’t think comparing what comes out of HTTPBin’s parser is sufficient to see the issue - I only see two differences:
the boundary string in the Content-Type; that’s intentionally random and so not relevant
the Accept header from Curl is not present in the other
It’s worth a try to add that header; some HTTP implementations are more selective about the headers they expect.
Otherwise you’ll need the actual bytes being sent in the two requests - there’s evidently some difference, since Pipedream shows a slightly different shape, despite HTTPBin seeing the same values.
I was able to get the post text fields to show up in pipe dream as text by adding [“Content-Type”: “text/plain”] to the payload tuple.
It still does not work on the vendor site. I reached out to the vendor and he suggested it may be the boundary that is causing the issue. I have the logs of the POST request from the vendor.
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
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:
I believe you may be right about the content-length. I setup a local server to capture raw post dumps and could not really see why the httpoison request would fail while the insomnia request works fine as both requests looked correct. Testing it with pipedream showed no errors and I was able to download the attached file.
If some servers don’t like content length on the fields, that would explain why I get a request 400 from this vendor. I reached out to them asking about it.