Soap module's all acting strange in lambda

Serverless Framework
1

Hi Everyone,

I have a 9 service API about to go into production. One of our tiers wraps calls to a soap service, using node-soap (or strong-soap) to call the remote service. The module that calls the service works in the following environments:

  1. Locally on V8.x.x and v 6.10.3
  2. Ec2 instance running the environment AWS reports as in the lambda containers
  3. both using babel-node and node only variants. on EC2 and locally.

the error in cloud watch points to the clientCreate constructor thinking a URL string (that works in all other environments) has an illegal character. These are the details:

//url parameter
const url = ‘https://apitest.integrapay.com.au/basic/PayLinkService.svc?WSDL’;

Error:

2017-08-28T13:53:44.608Z	4de51b86-8bf8-11e7-a11d-b3126a873aeb	this is the error from create client: TypeError: The header content contains invalid characters
at ClientRequest.OutgoingMessage.setHeader (_http_outgoing.js:360:11)
at new ClientRequest (_http_client.js:85:14)
at Object.exports.request (http.js:31:10)
at Object.exports.request (https.js:199:15)
at Request.start (/var/task/node_modules/request/request.js:755:32)
at Request.end (/var/task/node_modules/request/request.js:1525:10)
at end (/var/task/node_modules/request/request.js:567:14)
at Immediate.<anonymous> (/var/task/node_modules/request/request.js:581:7)
at runCallback (timers.js:672:20)
at tryOnImmediate (timers.js:645:5)
at processImmediate [as _immediateCallback] (timers.js:617:5)

I’m happy to post more but I’m sure its either something odd in container’s node install or perhaps babel related. Anyone seen anything like this?

2

Sounds like a strange one!

Can you try logging the headers out before making the request? A few issues on the requests repo suggest a potential issue with newlines or other unprintable characters…

3

Oh thanks for reminding me this was open Rowan, I reported the fix to AWS but not here.

Ok so I need to go back and do some further investigation as I’m not totally certain if the issue was just the strong-soap client (or any of the other clones in its family) borking or Lambda + soap.

The issue turned out to be fixed by removing a function from the object prototype that we had added. The soap client (seemingly only in lambda) borks with the modified prototype with the lovely error above.

Once I moved the function to just being a regular function no such error.

Once we go live (3 weeks to go and 6 weeks work :expressionless: ) ill go back and see what combinations cause it and report back if there is anything of import.

Cheers
b

1 Like