Account
I am a
Développeur
Product(s)
Earned badges
Achievement: Latest Unlocked
Preferences
Replies
Topics Started
Topic Started
This user has not created any forum posts.
Replies Created
Reply to: Trouble uploading a document through multipart/form-data via Oracle's UTL_HTTP
Friday, May 18, 2018 at 05:03amThanks 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:
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!
Reply to: Trouble uploading a document through multipart/form-data via Oracle's UTL_HTTP
Friday, May 18, 2018 at 09:35amI 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 objThe 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:startxref 82821 %%EOF ----THISxisMYxBoundary Content-Disposition: form-data; name="payload" { "name": "Test_2" } ----THISxisMYxBoundary--
{"entity":null,"packageId":null,"messageKey":"http.status.406","technical":"","m essageLanguage":null,"parameters":{},"message":"Not Acceptable","code":406,"name":"Not Acceptable"}
Reply to: Trouble uploading a document through multipart/form-data via Oracle's UTL_HTTP
Friday, May 18, 2018 at 10:09amFixed 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
Reply to: Trouble uploading a document through multipart/form-data via Oracle's UTL_HTTP
Friday, May 18, 2018 at 10:28amSure 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
Reply to: Trouble uploading a document through multipart/form-data via Oracle's UTL_HTTP
Monday, May 21, 2018 at 09:34amWell, 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!
Subscriptions
This user is not subscribed to any release notes.
Subscriptions Release Notes
This user is not subscribed to any release notes.