replace request & httpntlm with axios & axios-ntlm

[vision10]

This is my attempt to replace request and httpntlm packages with axios and axios-ntlm

Its not perfect yet and there are still some issues that need to be addressed:

• axios does not handle multipart options.
  • axios recommends to use form-data package for attachments, but I don't know if we should include another package or let the user handle this
• requestStream method does not return a request stream but a data response as a stream (because axios does not return the request stream, if only has the option to return the response as a stream with options.responseType='stream')
• a few tests need some rewriting (I have adjusted a few to work with the new packages as best as I knew/could)

I have updated a few packages (those with minor changes)
Some files have a few more changes because of vs code text autoformat (mainly whitespaces)
On a personal note, I don't think Promises mix well together with callbacks, so maybe callbacks should be dropped in a future version if axios is adopted ?

[coveralls]

Coverage increased (+0.07%) to 95.133% when pulling ade889f on vision10:master into 95fa71f on vpulim:master.

[jsdevel]

@vision10 please get the build to pass.

[j0k3r]

Something got broken with version 0.40.0 (I don't know if it's directly related to that PR).
I've tested to update the lib soap-as-promised and tests are failing.

• tests with soap 0.40.0: https://github.com/20minutes/soap-as-promised/runs/3008231406 ❌
• tests with soap 0.39.0: https://github.com/20minutes/soap-as-promised/runs/3008242162 ✅

[jsdevel]

@j0k3r can you submit a PR?

[j0k3r]

I didn't take a closer look atm. Maybe @vision10 can have an idea?

[vision10]

I think you need to use createClientAsync in your tests

[renanwilliam]

with this PR we lost support for sending attachments in MTOM?

[renanwilliam]

just to inform I have checked and we have a project MTOM attachments working fine on 0.39.0 and after upgrade to 0.40.0 it's stopped to work. This pull request is a breaking change.

[vision10]

Yes, I said it in the beginning, axios does not handle attachments automatically like request did, and a decision is needed if we should include another pachage or let the user handle them

[renanwilliam]

Ok but isn't better decide it and implement before release it?

[j0k3r]

I agree this is a BC change, but before 1.0.0, everything can be broken.
What you should do @renanwilliam is

• revert to 0.39.0,
• add a test unit to ensure MTOM attachements are working
• let Dependabot create a PR with newest version (and fail for upgrading to 0.40.0)
• wait until a new version of node-soap pass your test and then you'll be able to merge it

[renanwilliam]

I still think that isn't make sense release this change considering doesn't have any real benefit that justify a feature loss (it is just a replacement of request by axios). It can be worked in separate branch or a RC release until this open issues are fixed.

Anyway, I think that will be a good mention it in documentation about this BC.

[scagood]

I have just upgraded from 0.39.0 to 0.40.0 and for some reason the ClientSSLSecurity and ClientSSLSecurityPFX dont work anymore.

This I can only assume it is associated to this PR 👀

[olliswe]

I have just upgraded from 0.39.0 to 0.40.0 and for some reason the ClientSSLSecurity and ClientSSLSecurityPFX dont work anymore.

This I can only assume it is associated to this PR 👀

Same here...

[wagnerch]

SOAP faults also appear to be broken by this PR.

const soap = require("soap");

(async () => {
    const client = await soap.createClientAsync("http://www.dneonline.com/calculator.asmx?wsdl");

    try {
        const res = await client.AddAsync ({
            "intA": "1",
            "intB": "a"
        });
        console.log(res[0]?.AddResult);
    } catch (error) {
        console.log("ERROR:", error?.message);
    }
}) ();


C:> npm install [email protected]
C:> node .\soap.js
ERROR: Request failed with status code 500

C:> npm install [email protected]
C:> node .\soap.js
ERROR: soap:Client: System.Web.Services.Protocols.SoapException: Server was unable to read request. ---> System.InvalidOperationException: There is an error in XML document (1, 326). ---> System.FormatException: Input string was not in a correct format.
   at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)
   at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)
   at System.Xml.XmlConvert.ToInt32(String s)
   at Microsoft.Xml.Serialization.GeneratedAssembly.XmlSerializationReader1.Read1_Add()
   at Microsoft.Xml.Serialization.GeneratedAssembly.ArrayOfObjectSerializer.Deserialize(XmlSerializationReader reader)
   at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events)
   --- End of inner exception stack trace ---
   at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle, XmlDeserializationEvents events)
   at System.Xml.Serialization.XmlSerializer.Deserialize(XmlReader xmlReader, String encodingStyle)
   at System.Web.Services.Protocols.SoapServerProtocol.ReadParameters()
   --- End of inner exception stack trace ---
   at System.Web.Services.Protocols.SoapServerProtocol.ReadParameters()
   at System.Web.Services.Protocols.WebServiceHandler.CoreProcessRequest()

[scagood]

I found the same @wagnerch my solution was just to add the following to my entry point:

require('axios').defaults.validateStatus = () => true;

I will note this only work for me as this is the only package in my entire deps tree that uses axios 👀

I will note that any error handling you have will probably not work now also as the errors come formatted differently, but that is at least something we can handle in our client code.

I should probably make a PR to change the request options here also though 👀

[wagnerch]

@scagood Yeah, unfortunately I use axios, and it is also used in Azure which I also use, so setting this as a default wouldn't work for me. Not sure what the scoping of this default would be? I don't think the exception behavior should change because the underlying HTTP engine has changed.

I'll stick on 0.39.0 for now, and see where things go.

[wagnerch]

@scagood Thanks for the tip, submitted a PR to fix it. It looks like the requestStream pieces are broken with restoring the status code behavior that requests had, haven't had a chance to investigate it.

[bigplayalman]

for anyone having an issue with this, since this is using axios you need to change your options

import https from 'https';

const agent = new https.Agent({  
  rejectUnauthorized: false,  
  pfx: 'pfx buffer',  
  passphrase: 'password',  
})

const options = {  
  wsdl_options: {  
    httpsAgent: agent,  
  }  
}

[isaacgrimaldo]

other way to use it

const agent = new https.Agent({
    cert: certpub,
    key: certpri,
  });

  const options = {
    envelopeKey: 'soapenv',
    wsdl_options: {
      httpsAgent: agent,
    },
  };