|
If you were logged in you would be able to see more operations.
|
|
|
|
Environment:
|
All platforms
|
|
| Resolution Date: |
13/Oct/04 06:20 AM
|
|
Client cannot handle '<' character and '>' characters while deserializing a returned string.
e.g.
If server response contains:
<echoStringReturn xsi:type="xsd:string">hello< world</echoStringReturn>
the client get the return value as:
< world
If server response contains:
<echoStringReturn xsi:type="xsd:string">hello> world</echoStringReturn>
the client get the return value as:
> world
|
|
Description
|
Client cannot handle '<' character and '>' characters while deserializing a returned string.
e.g.
If server response contains:
<echoStringReturn xsi:type="xsd:string">hello< world</echoStringReturn>
the client get the return value as:
< world
If server response contains:
<echoStringReturn xsi:type="xsd:string">hello> world</echoStringReturn>
the client get the return value as:
> world |
Show » |
|
Bug
Closed
Major
Client cannot handle '<' and '>' characters in deserializing a returned string
Expat parser did not need any fix, it works.
I used the following XML for testing with echoSting of base sample and it works:
<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <soap:Body> <PaymentConfirmResponse xmlns="http://service.zx.chinavnet.com/v1.0/"> <PaymentConfirmResult> <SenderID/> <Result>-10021</Result> <ErrorDescription>XXXXX</ErrorDescription> </PaymentConfirmResult> </PaymentConfirmResponse> </soap:Body> </soap:Envelope>
One more observation: Xerces parser is much slower than Expat parser in this case.