soap 0.20.0 → 0.24.0

package/.editorconfig

@@ -1,23 +1,23 @@
-# EditorConfig for the node-soap library - head over to editorconfig.org to see if you editor supports this file.
-
-# this is the topmost .editorconfig file
-root = true
-
-[*]
-end_of_line = lf
-insert_final_newline = true
-
-[*.xml]
-insert_final_newline = false
-
-[*.js]
-indent_style = space
-indent_size = 2
-
-[*.json]
-indent_style = space
-indent_size = 2
-
-[{package.json,.travis.yml}]
-indent_style = space
-indent_size = 2
+# EditorConfig for the node-soap library - head over to editorconfig.org to see if you editor supports this file.
+
+# this is the topmost .editorconfig file
+root = true
+
+[*]
+end_of_line = lf
+insert_final_newline = true
+
+[*.xml]
+insert_final_newline = false
+
+[*.js]
+indent_style = space
+indent_size = 2
+
+[*.json]
+indent_style = space
+indent_size = 2
+
+[{package.json,.travis.yml}]
+indent_style = space
+indent_size = 2

package/.jshintrc

@@ -1,29 +1,29 @@
-{
-  "bitwise":false,
-  "boss":true,
-  "expr":true,
-  "camelcase":false,
-  "curly":false,
-  "eqeqeq":true,
-  "freeze":true,
-  "immed":true,
-  "indent":2,
-  "latedef":"nofunc",
-  "laxbreak":true,
-  "laxcomma":true,
-  "newcap":true,
-  "noarg":true,
-  "node":true,
-  "strict": true,
-  "trailing":true,
-  "undef":true,
-  "predef": [
-    "describe",         // Used by mocha
-    "it",               // Used by mocha
-    "xit",               // Used by mocha
-    "before",           // Used by mocha
-    "beforeEach",       // Used by mocha
-    "after",            // Used by mocha
-    "afterEach"         // Used by mocha
-  ]
-}
+{
+  "bitwise":false,
+  "boss":true,
+  "expr":true,
+  "camelcase":false,
+  "curly":false,
+  "eqeqeq":true,
+  "freeze":true,
+  "immed":true,
+  "indent":2,
+  "latedef":"nofunc",
+  "laxbreak":true,
+  "laxcomma":true,
+  "newcap":true,
+  "noarg":true,
+  "node":true,
+  "strict": true,
+  "trailing":true,
+  "undef":true,
+  "predef": [
+    "describe",         // Used by mocha
+    "it",               // Used by mocha
+    "xit",               // Used by mocha
+    "before",           // Used by mocha
+    "beforeEach",       // Used by mocha
+    "after",            // Used by mocha
+    "afterEach"         // Used by mocha
+  ]
+}

package/.travis.yml

@@ -1,22 +1,22 @@
-sudo: false
-language: node_js
-notifications:
-  email: false
-node_js:
-  - 4.0
-  - 6.9.4
-  - 7.4.0
-  - node
-env:
-  - CXX=g++-4.8
-addons:
-  apt:
-    sources:
-      - ubuntu-toolchain-r-test
-    packages:
-      - g++-4.8
-before_install:
-  - npm -g install npm@latest
-script:
-  - npm run cover
-  - npm run coveralls
+sudo: false
+language: node_js
+notifications:
+  email: false
+node_js:
+  - 4.8.4
+  - 6.9.4
+  - 7.4.0
+  - "lts/*"
+env:
+  - CXX=g++-4.8
+addons:
+  apt:
+    sources:
+      - ubuntu-toolchain-r-test
+    packages:
+      - g++-4.8
+before_install:
+  - npm -g install npm@latest
+script:
+  - npm run cover
+  - npm run coveralls

package/CONTRIBUTING.md

@@ -1,58 +1,52 @@
-# Contribution Guidelines
-
-Thank you for your support!  node-soap wouldn't be where it is today without contributors like you who are willing to take the time to improve it for everyone else.
-
-Because SOAP Web Services can differ amongst implementations, there is high risk involved in making changes.  What works for your WSDL, might not work with another.  It is therefore _essential_ that contributors to node-soap adhere to these guidelines.
-
-## Filing issues
-* Please look through the issues that are currently open in the attempt to find one that matches yours.
-* If you find an issue that matches yours, please submit your documentation about it there as it will help everyone understand it more.
-* If you plan on fixing the issue, please take the time to fix it first and then provide a Pull Request.
-* Please be descriptive in your issue titles  I.E. "Error occurs when calling client.foo on WSDL without import element."
-
-## Submitting a Pull Request
-* Pull Requests **must be rebased to the latest version of master and _squashed to a single commit_** i.e. `git checkout master;git pull upstream master;git checkout feature-branch;git rebase -i master`
-* Pull Requests **must have accompanying tests** (either Unit or Request/Response Sample tests are welcome). Your chances of getting the PR merged are very low if you don't provide any tests.
-* Pull Requests must have passing travis builds.
-* Pull Requests must be able to merge automatically from github.
-* Please **do not close a pull request due to a request to rebase**.  Git is a powerful VCS and deserves your time in learning how to rebase properly.  Pull Requests are updated automatically on github when you force push to your branch after rebasing.
-
-Very useful articles/help on this topic:
-  - [GitHub Help - About Git rebase](https://help.github.com/articles/about-git-rebase/)
-  - [GitHub Help - Using Git rebase](https://help.github.com/articles/using-git-rebase/)
-
-* Please use descriptive commit messages.  Commit messages are used during the creation of history and release notes.  You'll make the job of maintainers much easier by doing this.
-
-## Making Changes
-* Any and all pull requests to change documentation or typos are welcome!
-* Any WSDL checked in should be as small and as generic as possible.  This is to keep the size of the codebase from growing too large and to keep the reason for submitting the WSDL clear I.E. if the WSDL was submitted because attributes were not being parsed on response XML, then it would be appropriate to submit a WSDL that defines a response with attributes *and nothing else*.  If you find an issue with the parser not being able to handle large WSDLs, then it would be appropriate to submit a large WSDL to recreate the issue with.
-* If your issue is WSDL related:
-````
-    1. Make your WSDL as generic as possible to recreate the issue
-    2. Add the WSDL to the appropriate path in test/wsdl.
-    3. Commit your changes to a feature branch within your fork.
-    4. Issue a pull request.
-````
-
-* If your issue is client related:
-````
-    1. Capture the request / response XML via client.lastRequest and client.lastResponse as well as the WSDL.
-    2. Make the WSDL, request, and response XML as generic as possible.
-    3. Only include the messages or operations that are having issues.
-    4. Add the appropriate files to test/request-response-samples (see the README therein)
-    5. Commit your changes to a feature branch within your fork.
-    6. Issue a pull request
-````
-
-* If your issue is neither WSDL nor client related:
-````
-    1. Provide a test of some form in an appropriate *-test.js file under test/
-    2. Commit your changes to a feature branch within your fork.
-    3. Issue a pull request.
-````
-
-## Issue Expiration
-Any pull request or issue filed is subject to an expiration date.  We will close any open issue that has not received a response within a 2 week timeframe.  The goal is not to sweep dirt under the rug, but to keep the focus on merging in pull requests.  Please provide pull requests that meet the above criteria wherever possible.
-
-## Other ways you can contribute
-Please add response, request, and WSDL files to test/wsdl, and test/request-response-samples (see README therein).  Doing so documents behavior and reduces the likelihood that bugs will be introduced by future pull requests.
+# Contribution Guidelines
+
+Thank you for your support!  node-soap wouldn't be where it is today without contributors like you who are willing to take the time to improve it for everyone else.
+
+Because SOAP Web Services can differ amongst implementations, there is high risk involved in making changes.  What works for your WSDL, might not work with another.  It is therefore _essential_ that contributors to node-soap adhere to these guidelines.
+
+## Submitting a Pull Request
+* Pull Requests **must be rebased to the latest version of master and _squashed to a single commit_** i.e. `git checkout master;git pull upstream master;git checkout feature-branch;git rebase -i master`
+* Pull Requests **must have accompanying tests** (either Unit or Request/Response Sample tests are welcome). Your chances of getting the PR merged are very low if you don't provide any tests.
+* Pull Requests must have passing travis builds.
+* Pull Requests must be able to merge automatically from github.
+* Please **do not close a pull request due to a request to rebase**.  Git is a powerful VCS and deserves your time in learning how to rebase properly.  Pull Requests are updated automatically on github when you force push to your branch after rebasing.
+
+Very useful articles/help on this topic:
+  - [GitHub Help - About Git rebase](https://help.github.com/articles/about-git-rebase/)
+  - [GitHub Help - Using Git rebase](https://help.github.com/articles/using-git-rebase/)
+
+* Please use descriptive commit messages.  Commit messages are used during the creation of history and release notes.  You'll make the job of maintainers much easier by doing this.
+
+## Making Changes
+* Any and all pull requests to change documentation or typos are welcome!
+* Any WSDL checked in should be as small and as generic as possible.  This is to keep the size of the codebase from growing too large and to keep the reason for submitting the WSDL clear I.E. if the WSDL was submitted because attributes were not being parsed on response XML, then it would be appropriate to submit a WSDL that defines a response with attributes *and nothing else*.  If you find an issue with the parser not being able to handle large WSDLs, then it would be appropriate to submit a large WSDL to recreate the issue with.
+* If your Pull Request is WSDL related:
+````
+    1. Make your WSDL as generic as possible to recreate the issue
+    2. Add the WSDL to the appropriate path in test/wsdl.
+    3. Commit your changes to a feature branch within your fork.
+    4. Issue a pull request.
+````
+
+* If your Pull Request is client related:
+````
+    1. Capture the request / response XML via client.lastRequest and client.lastResponse as well as the WSDL.
+    2. Make the WSDL, request, and response XML as generic as possible.
+    3. Only include the messages or operations that are having issues.
+    4. Add the appropriate files to test/request-response-samples (see the README therein)
+    5. Commit your changes to a feature branch within your fork.
+    6. Issue a pull request
+````
+
+* If your Pull Request is neither WSDL nor client related:
+````
+    1. Provide a test of some form in an appropriate *-test.js file under test/
+    2. Commit your changes to a feature branch within your fork.
+    3. Issue a pull request.
+````
+
+## Issue Expiration
+Any pull request filed is subject to an expiration date. We will close any open Pull Request that has not received a response within a 2 week timeframe.  The goal is not to sweep dirt under the rug, but to keep the focus on merging in pull requests.  Please provide pull requests that meet the above criteria wherever possible.
+
+## Other ways you can contribute
+Please add response, request, and WSDL files to test/wsdl, and test/request-response-samples (see README therein).  Doing so documents behavior and reduces the likelihood that bugs will be introduced by future pull requests.

package/History.md

@@ -1,11 +1,61 @@
+0.24.0 / 2018-04-05
+===================
+* [DOC] Error on custom deserializer example (#1000)
+* [DOC] Fix broken link
+* [DOC] adding bullets to separate each option
+* [DOC] changed ClientSSLSecurity to ClientSSLSecurityPFX in the readme file
+* [DOC] clarify section on client events in Readme.md (#989)
+* [ENHANCEMENT] Added one-way response configuration options
+* [ENHANCEMENT] Adding support for SOAP 1.2 Envelope Headers in the server side (#1003)
+* [ENHANCEMENT] Enable multiArgs during promisification
+* [ENHANCEMENT] add Client.wsdl for accessing client.wsdl during soap.createClient() (#990)
+* [ENHANCEMENT] add option to remove element-by-element namespacing of json arrays (#994)
+* [ENHANCEMENT] add rawRequest to callback arguments (#992)
+* [FIX] Fixed checking for empty obj.Body before further actions (#986)
+* [FIX] Lookup definitions in child element first (#958)
+* [FIX] only detect xsi:nil if its value is `true` (#983)
+* [MAINTENANCE] Updating the coverage to use the new version of Istanbul framework, the nyc.
+* [MAINTENANCE] Upgrade Lodash to 4.17.5 (#1001)
+
+0.23.0 / 2017-10-18
+===================
+* [FIX] Fixing tests broken by #979
+* [FEATURE] replace non identifier chars to underscore (#978)
+* [FEATURE] Pool keep alive connections if forever option is used (#979)
+* [MAINTENANCE] Use assert.ifError function in tests (#976)
+* [FEATURE] Add function support for server addSoapHeader (#977)
+
+0.22.0 / 2017-10-02
+===================
+* [ENHANCEMENT] Added `forever` option to `ClientSSLSecurity` in order to allow `keep-alive` connections. (#974)
+* [ENHANCEMENT] Added `preserveWhitespace` option to prevent the client from trimming resolved `String` values. (#972)
+* [MAINTENANCE] Removed `compres` dependency in favor of `zlib`. (#971)
+* [MAINTENANCE] (Security) Updated `debug` dependency to avoid possible vulnerability. (#973)
+* [FIX] Updated `.travis.yml` to test against latest `node.js 4.8.x` release to avoid Travis CI error.
+* [FIX] Fix performance bug at POJO to XML conversion. (#968)
+* [ENHANCEMENT] Added possibility to override the `bluebird.js` suffix (default: "async"). (#961)
+* [DOC] Updated the `Security` section by listing all available optional methods. (#966)
+
+0.21.0 / 2017-08-28
+===================
+* [DOC] Removed issues from Contributing Readme (#963)
+* [DOC] Add server option details to readme.md (#965)
+* [DOC] Added details to clientSSLSecurity (#960)
+* [ENHANCEMENT] Added 'useEmptyTag' wsdlOption, which if set, creates <Tag /> instead of <Tag></Tag> if no body is present (#962)
+* [ENHANCEMENT] Add typescript support (#955)
+* [FIX] `path.resolve` cannot resolve a null path (#959)
+* [MAINTENANCE] Updated minimum node version to 4.0.0 (#964)
+* [MAINTENANCE] Update `uuid` library to latest release (`3.1.0`) and use their newly introduced "modules" instead of the outdated/deprecated direct method calls.
+* [MAINTENANCE] Fixed JSHint indentation errors in `test/client-test.js`.
+
 0.20.0 / 2017-08-08
 ===================
-* [ENHANCEMENT] Added `bluebird.js` promise library in order to provide `[methodName]Asyc` in `Client` (#956) 
+* [ENHANCEMENT] Added `bluebird.js` promise library in order to provide `[methodName]Asyc` in `Client` (#956)
 * [ENHANCEMENT] Added `option` to handle `nilAsNull` in `SOAP` responses (#952)
 * [ENHANCEMENT] Added `option` to return a `SOAP Fault` instead of `stack` (error) on bad request (#951)
 * [MAINTENANCE] Removed uneccessary variable declaration in `http.js` (#948)
 * [ENHANCEMENT] Added possibiltiy to alter `XML` before it is sent (#943)
-* [FIX] Updated vulnerable module `finalhandler` to version `^1.0.3` (#946) 
+* [FIX] Updated vulnerable module `finalhandler` to version `^1.0.3` (#946)
 * [ENHANCEMENT] Added possibility to submit `XML`-Strings to SOAP Client API (#918)
 
 0.19.2 / 2017-06-12

package/LICENSE

@@ -1,7 +1,7 @@
-Copyright (C) 2013 Vinay Pulim
-
-Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+Copyright (C) 2013 Vinay Pulim
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

package/PUBLISHING.md

@@ -1,28 +1,28 @@
-Publishing
-===================
-
-This document describes the steps a maintainer of this project generally takes in
-order to publish a newer version of `node-soap`.
-
-## Ideals
-* Pull Requests that alter, add, or correct functionality have a single commit.
-* All commit messages are descriptive.
-* Maintainers spend little time looking at git history to update HISTORY.md.
-
-## Process
-1. Checkout the commit that you would like to publish.  This is usually accomplished
-   with `git checkout master`.
-2. Run `git log --oneline`
-3. Copy the commit messages above the last release commit message into History.md.
-4. Consolidate the commit messages:
-  * Remove any futile commits I.E. "Removing white space"
-  * Remove Pull Request merge commits.  In some cases, you may need to reference the issue in
-    order to get the commit message for that Pull Request.
-  * Prefix commit messages with "Enhancement", "Fixed", "Deprecated" and so forth
-    accordingly.
-  * Reword line items as necessary.
-5. Update package.json to the appropriate version for the release.
-6. Commit your changes to master and push them up to github.
-7. Use the github interface to create a tag.
-  * Use existing release notes as a reference when adding the release notes to github.
-8. `npm publish`.
+Publishing
+===================
+
+This document describes the steps a maintainer of this project generally takes in
+order to publish a newer version of `node-soap`.
+
+## Ideals
+* Pull Requests that alter, add, or correct functionality have a single commit.
+* All commit messages are descriptive.
+* Maintainers spend little time looking at git history to update HISTORY.md.
+
+## Process
+1. Checkout the commit that you would like to publish.  This is usually accomplished
+   with `git checkout master`.
+2. Run `git log --oneline`
+3. Copy the commit messages above the last release commit message into History.md.
+4. Consolidate the commit messages:
+  * Remove any futile commits I.E. "Removing white space"
+  * Remove Pull Request merge commits.  In some cases, you may need to reference the issue in
+    order to get the commit message for that Pull Request.
+  * Prefix commit messages with "Enhancement", "Fixed", "Deprecated" and so forth
+    accordingly.
+  * Reword line items as necessary.
+5. Update package.json to the appropriate version for the release.
+6. Commit your changes to master and push them up to github.
+7. Use the github interface to create a tag.
+  * Use existing release notes as a reference when adding the release notes to github.
+8. `npm publish`.