Investigation of WebServices error handling and recovery

RESOLVED INCOMPLETE

Status

RESOLVED INCOMPLETE
15 years ago
10 months ago

People

(Reporter: bugs, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

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.

Comment 1

15 years ago
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

Updated

10 months ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.