SOAP fault coerces SOAP 1.2 request to SOAP 1.1 response

[salmipa]

Looks like return a fault according to your documentation (throw { Fault: .... }) causes coercion to SOAP 1.1.

Description/Steps to reproduce

Use SOAP 1.2 request and return a fault.

Link to reproduction sandbox

gentest3.zip

Expected result

Expected result is SOAP 1.2 Envelope

Additional information

win32 x64 16.13.0
ltpp0000-paci-app@1.0.0 C:\temp\crap\test3
├── cors@2.8.5
├── debug@4.3.3
├── express@4.17.1

├── helmet@4.6.0
├── morgan@1.10.0
└── strong-soap@3.3.1

[salmipa]

Debugging and analysing it further. It has something to do with multiple port types and bindings. If I removed all but SOAP 1.2 port type, it worked. I was using your world famous stock quote sample wsdl.

[achrinza]

Thanks for opening an issue, @slamipa. We'll review the issue and see if we can create a fix. If preferred, you can also open a PR with a fix and regression tests and we'll help land it for the next release.

For security reasons, it is advisable not to provide ZIP files. For future issues, please consider uploading the reproduction sandbox to either Code Sandbox or as a public Git repository.

I've re-published the reproduction sandbox (along with a SOAP client) here: https://github.com/achrinzatest/strong-soap-issue-345

---

After some testing, I was able to replicate the issue from my end. It seems that this is where the issue is:

strong-soap/src/server.js

Lines 177 to 178 in c3a9ebd

	if (portPathname === pathname)
	return port.binding;

The Server Port is being filtered by their address location, but are not differentiated by the "port type" (e.g. SOAP 1.1, SOAP 1.2). This means if we re-arrange the Ports to have SOAP 2.0 as the first, it'll solve the immediate problem (Though the problem just moved to the other Ports).

Hence, the crux of the bug is that the first Port with a matching address location regardless of the protocol will be used even if the actual protocol used in the HTTP request is different