Recently I was developing an app where the SOAP response included null values, which are currently not handled properly by nsDefaultSOAPEncoder because the SOAPPropertyBags don't take null items. What was happening was this: - DefaultSOAPEncoder calls nsSOAPPropertyBag::AddProperty with a null value - AddProperty discovers the null value and returns a failure value - DefaultSOAPEncoder stupidly decides to abort the whole thing I was using the WSDL API - and this failure made it so none of my callbacks was reached. This is one instance that can be patched by making DefaultSOAPEncoder handle null values properly, but it seems that the error handling was installed reflexively, without any real thought about the consequences. It seems like it'd be useful to look at all the "if (NS_FAILED(rv)) return rv;"s and think about what might cause them to be triggered, and what the impact on app developers might be. It's a given that this code is buggy, some recovery to circumvent those bugs would be nice ;-) Proper error handling is also a requirement for a technology we want people to leverage on the client.
Another problem is the information we pass to the listener when something fails isn't very clear where the failure happened and who (client or server) reported it. We also have some goto sections that do nothing if we don't find a decoder/encoder for a type.
Assignee: web-services → nobody
QA Contact: doronr → web-services
Native WSDL and SOAP support has been removed from Mozilla 1.9/Firefox 3
Status: NEW → RESOLVED
Last Resolved: 11 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.