2019-03-16 19:25:40 UTC - Perry Dykes: API Gateway folks, using IBM Cloud Functions with an action that receives XML data, and upon testing it (ending with the .http HTTP Method for POST), all good, in fact the code is nearly the demo code to simplify the testing I'm working through: ``` function main(args) { decoded = new Buffer(args.__ow_body, 'base64').toString('utf-8') // console.log("incoming text block", decoded); return { body: decoded, headers: { "Content-type" : "application/json" }, "statusCode" : 200 }; } ```
The issue, once I configure (only use the UI, so dont really change fancier options, etc... currently). Working with the actions folks, they should me when the .http action is link from the API Gateway to the Cloud Functions Gateway, a form of authentication is enabled. Net, the API gateway does accept the XML, but something between the API gateway to the Action has a problem. Here is my curl -v debug sequence when I hit the Cloud Functions/API Explorer URI that is connected to a fully and functionally correct xml processing agent: ``` curl -v H 'Content-Type: application' -H 'Accept: application/json' -X POST -d@c6500_failed_psu.xml <https://0d9d6615.eu-de.apiconnect.appdomain.cloud/9374cde5-255f-41b2-ba73-dba0d0ce4eab/api/v1/mvs/cisco_test> Note: Unnecessary use of -X or --request, POST is already inferred. * Trying 158.177.136.170... * TCP_NODELAY set * Connected to 0d9d6615.eu-de.apiconnect.appdomain.cloud (158.177.136.170) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /etc/ssl/cert.pem CApath: none * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Client hello (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Client hello (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-ECDSA-AES256-GCM-SHA384 * ALPN, server accepted to use http/1.1 * Server certificate: * subject: CN=*.eu-de.apiconnect.appdomain.cloud * start date: Dec 27 01:58:56 2018 GMT * expire date: Mar 27 01:58:56 2019 GMT * subjectAltName: host "0d9d6615.eu-de.apiconnect.appdomain.cloud" matched cert's "*.eu-de.apiconnect.appdomain.cloud" * issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3 * SSL certificate verify ok. > POST /9374cde5-255f-41b2-ba73-dba0d0ce4eab/api/v1/mvs/cisco_test HTTP/1.1 > Host: 0d9d6615.eu-de.apiconnect.appdomain.cloud > User-Agent: curl/7.54.0 > Content-Type: application > Accept: application/json > Content-Length: 22078 > Expect: 100-continue > < HTTP/1.1 100 Continue * We are completely uploaded and fine < HTTP/1.1 500 Internal Server Error < Server: openresty/1.13.6.1 < Date: Sat, 16 Mar 2019 19:29:44 GMT < Content-Type: application/json < Content-Length: 84 < Connection: keep-alive < X-Request-Id: U8KhyjtJD7LsMSO3gCKVGdjCZHbskZhB < {"code":500, "message":"Oops. Something went wrong. Check your URI and try again."} • Connection #0 to host 0d9d6615.eu-de.apiconnect.appdomain.cloud left intact ``` https://openwhisk-team.slack.com/archives/C3TP33Y2U/p1552764340006500 ---- 2019-03-16 19:38:43 UTC - Perry Dykes: As denoted above, the API gateway does seem to accept the data ok, and then things go awry in the Internal Server processing. On the API Gateway endpoint, I have NOT configured OAuth nor API Key authentications. The GET curl request can go from the API Gateway to the Cloud Functions Get Action and return a JSON. The issue is seems to be related to the XML POST processing stream between the API Gateway to the Cloud Functions Action. I have tested the Cloud Functions Action and it works via direct CURL interaction. Let me know if their is something in the API Gateway I need for diagnosis and testing to through this blocker. https://openwhisk-team.slack.com/archives/C3TP33Y2U/p1552765123008400 ----