aklock's account

Thanks Haris. I'm definitely not doing the base64 thing, but I'm not sure exactly how the binary data is being sent. In Oracle when I try to show what is being sent I get a hexadecimal representation of the data so it looks like I'm sending you something. I'm happy to install Fiddler and do some more troubleshooting on my end. Will keep you posted. In the meantime, I ran another test using the headers in your example. The main difference being: Accept: application/json Whereas the docs show to use text/html. When I changed it to application/json I now get the following error:

{"messageKey":"http.status.406","technical":"","messageLanguage":null,"packageId
":null,"entity":null,"message":"Not
Acceptable","parameters":{},"code":406,"name":"Not Acceptable"}

Which is sort of refreshing :) , just not sure how to fix it. I would think that it would use the package id from the URL . Thanks again!

I had trouble getting Fiddler to run properly on Linux, but did have luck with Charles. Pretty fun, so thanks for that. From the request contents, it does look like I'm sending out the PDF binary. The only thing that I did differently this time was that I re-ordered my parts to match your order in your last example and I also noticed that Connection was set to "close". So, I explicitly set it to "keep-alive" in my header, but still see the "close" line for some reason. Not sure what that would do, since I thought HTTP/1.1 defaults to keep-alive, but thought I would mention it. Does look like application/json is what your server is expecting, so maybe it is a documentation bug.

POST /api/packages/2HmThBe9eZopqozAMY63n6TZ5jY=/documents HTTP/1.1
Host: sandbox.esignlive.com
Authorization: Basic xxxxxxxxxxxxxx==
Accept: application/json
Content-Type: multipart/form-data; boundary="----THISxisMYxBoundary"
Content-Length: 83248
Connection: keep-alive
Connection: close


----THISxisMYxBoundary
Content-Disposition: form-data; name="file"; filename="Test_2.pdf"
Content-Type: application/pdf
%PDF-1.5
%����
1 0 obj

startxref
82821
%%EOF

----THISxisMYxBoundary
Content-Disposition: form-data; name="payload"

{ "name": "Test_2" }
----THISxisMYxBoundary--

The only other thing I can think of is the way that I'm calculating the Content-Length, which is just me adding up all the bytes that I'm sending out. I did try using chunked but got the same message as the previous example:

{"entity":null,"packageId":null,"messageKey":"http.status.406","technical":"","m
essageLanguage":null,"parameters":{},"message":"Not
Acceptable","code":406,"name":"Not Acceptable"}

Fixed the Connection: close issue. I needed to set the persistent connection support flag. UTL_HTTP.set_persistent_conn_support(TRUE); Still getting http.status.406 though

Sure thing!

POST /api/packages/2HmThBe9eZopqozAMY63n6TZ5jY=/documents HTTP/1.1
Host: sandbox.esignlive.com
Authorization: Basic BlahBlahBlahBlah==
Accept: text/html
Content-Type: multipart/form-data; boundary="----THISxisMYxBoundary"
Content-Length: 83248
Connection: keep-alive


----THISxisMYxBoundary
Content-Disposition: form-data; name="file"; filename="Test_2.pdf"
Content-Type: application/pdf
%PDF-1.5
%����
1 0 obj
...
startxref
82821
%%EOF

----THISxisMYxBoundary
Content-Disposition: form-data; name="payload"

{ "name": "Test_2" }
----THISxisMYxBoundary--

Returns:

HTTP/1.1 500 Internal Server Error
Server: nginx
Date: Fri, 18 May 2018 19:24:19 GMT
Content-Type: application/octet-stream
Transfer-Encoding: chunked
X-Powered-By: Undertow
Allow: GET, POST, HEAD, PUT, PATCH, DELETE
Connection: keep-alive

500: Unhandled Server Error

Well, this is sort of embarrassing. (But, in my defense I'm a database guy...) . I tested downloading the PDF again, just to re-confirm that it wasn't a corruption issue and it worked like a charm. I then started to think more about the message that was in the Charles output. "Failed to decode multipart body" . And started to wonder if my boundaries are just dumb. I was using, "----THISxisMYxBoundary" after all. So, I decided to use the one from your example, but noticed that for your multiparts you were injecting an extra "--" ontop of what you were setting as your boundary. After running a simple (non PDF) example, I finally was able upload a file.

POST /api/packages/2HmThBe9eZopqozAMY63n6TZ5jY=/documents HTTP/1.1
Host: sandbox.esignlive.com
Authorization: Basic BlahBlahBlah==
Content-Type: multipart/form-data; boundary="----THISxisMYxBoundary"
Content-Length: 357
Connection: keep-alive


------THISxisMYxBoundary
Content-Disposition: form-data; name="file"; filename="Test1.txt"
Content-Type: text/plain

This is my sample file content!
------THISxisMYxBoundary
Content-Disposition: form-data; name="payload"
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

{ "name": "Test1.txt" }

Finally! However, when I run the same fix for my PDF (the ultimate goal), the multipart error goes away and I get a JSON type message back. Still a 500, but at least something useful this time: Request:

POST /api/packages/2HmThBe9eZopqozAMY63n6TZ5jY=/documents HTTP/1.1
Host: sandbox.esignlive.com
Authorization: Basic BlahBlahBlah==
Accept: text/html
Content-Type: multipart/form-data; boundary="----THISxisMYxBoundary"
Transfer-Encoding: chunked
Connection: keep-alive


------THISxisMYxBoundary
Content-Disposition: form-data; name="file"; filename="Test_2.pdf"
Content-Type: application/pdf
%PDF-1.5
%����
1 0 obj
...
startxref
82821
%%EOF

------THISxisMYxBoundary
Content-Disposition: form-data; name="payload"

{ "name": "Test_2" }
------THISxisMYxBoundary--

Response:

{"messageKey":"error.internal.default","technical":"65533","message":"Unexpected
error. We apologize for any inconvenience this may have caused you, please try
again. If the problem persists, please contact our support
team.","code":500,"name":"Unhandled Server Error"}

Any idea what the 65533 is about? Maybe this time there might be something useful in the log. Thanks again for hanging in there with me!