|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #50547 SoapServer Fatal errror in WSDL mode
Submitted: 2009-12-21 20:18 UTC Modified: -
Avg. Score:4.4 ± 0.8
Reproduced:58 of 58 (100.0%)
Same Version:9 (15.5%)
Same OS:25 (43.1%)
From: rsumibcay at reddoor dot biz Assigned:
Status: Open Package: SOAP related
PHP Version: 5.2.12 OS: Ubuntu Linux
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2009-12-21 20:18 UTC] rsumibcay at reddoor dot biz
SoapServer dies with fatal error in WSDL mode when a soap argument is a ComplexType with a member defined as int in the XSD, but the member value is passed as a non-numeric string. 

Reproduce code:
1. Define a ComplexType with an int data member:

2. Define a WSDL that uses the ComplexType as an argument to the soap function:

3. Create a soap envelope with a non-numeric string as the value for the int data member:

4. Make a soap request using the soap envelope in step 3.

Expected result:
The SoapServer should not die with a fatal error. The SoapServer should respond with a SoapFault, or let the call pass through so the business logic (mapped handler) can do validation and handle the error appropriately.

Actual result:
500 HTTP response from server. The HTTP response body contains an error message and stack trace.

Fatal error: SOAP-ERROR: Encoding Violation of encoding rules in ...


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2010-02-01 09:48 UTC] jitka at darbujanova dot cz
I can confirm this. (
 [2011-02-24 09:54 UTC] mdekrijger at e-sites dot nl
Does anyone have an alternative solution for this problem? (while this bug remains 

We really want to provide some information about the wrong type in the return soap 
response. So implementing our SOAP services would be a much easier job.
 [2011-02-24 16:00 UTC] mdekrijger at e-sites dot nl
Xdebug might be the problem. When using xdebug_disable() before calling the 
handle() method, the server responds with a proper SOAP message which says that 
something went wrong.
 [2011-08-17 14:28 UTC] chinigo at gmail dot com
mdekrijger's suggestion about disabling Xdebug worked for me too. Adding 
xdebug_disable() immediately before the SOAP call resulted in a Fatal SOAP error 
being converted to a catchable SOAP fault.
 [2012-02-09 14:15 UTC] dp0 at yandex dot ru
Encoding: Violation of encoding rules
was my problem too, when trying to work with WSDL created in JAVA.

The problem was solved by moving to using the 1.2 version of SOAP on server and client.
 [2012-06-11 11:22 UTC] agastiya at gmail dot com
I also experience this when running on PHP 5.2+ and 5.3+. My script run flawlessly 
on PHP 5.1.6. so maybe the encoding rules were not applied strictly on version 5.1 
than on the newer version? 

I vote for adding option to let the call pass through so that more validation can 
be handled manually at PHP level.
 [2013-06-05 22:16 UTC] akg_67 at hotmail dot com
I experience this issue today. I am using PHP 5.4.4/MAMP on a MBP and also 
experienced same issue on my GoDaddy shared hosting service.

soapUI indicated line 817: Invalid double value in XML Response. Basically, one 
of the parameter on Line 817 has value "" instead of double as expected.

I haven't been able to figure out how to overcome this issue in PHP SOAPClient 
soapCall. I just have to wait until the incorrect value line is no longer in the 
XML response.

Exception: SOAP-ERROR: Encoding: Violation of encoding rules

*** Last Request Headers ***
string(249) "POST /ws/1.3 HTTP/1.0
Connection: close
User-Agent: PHP-SOAP/5.4.4
Content-Type: text/xml; charset=utf-8
SOAPAction: "LoanBrowseLoans"
Content-Length: 230
Authorization: Basic <redacted authorization string>
*** Last Request ***
string(230) "

*** Last Response Headers ***
string(255) "HTTP/1.0 200 OK
Content-Type: text/xml;charset=utf-8
Date: Wed, 05 Jun 2013 22:04:28 GMT
Server: ECS (sea/1C0B)
Set-Cookie:; Expires=Thu, 06-Jun-2013 
22:01:20 GMT; Path=/
Content-Length: 367010
Connection: close
*** Last Response ***
string(367010) "2013-06-05T15:04:28.391-07:00"
Can not process further due to error
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Jul 24 10:01:28 2024 UTC