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
----
