Closed Bug 126210 Opened 22 years ago Closed 14 years ago

SOAP responses are sometimes null after successful

Categories

(Core Graveyard :: Web Services, defect, P3)

All
Linux
defect

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: rayw, Assigned: doronr)

References

Details

Attachments

(2 files, 1 obsolete file)

Sometimes, with an unknown or perhaps a badly-behaving service, the xml http 
request layer returns a null document.  The http soap transport returns a null 
response but does not make an error out of it.  It would be clearer if a 
response-missing error were generated, even if we don't know exactly what this 
means.

This same general behavior seems to happen with both synchronous and 
asynchronous requests.
Here is a test case given me by a user who modified soapcall.html which
produces the problem (at least today it does).
Priority: -- → P3
Status: NEW → ASSIGNED
Hardware: Other → All
*** Bug 123506 has been marked as a duplicate of this bug. ***
I started several times to create a patch for this in the transport that checked
the response and generated an exception if there was none.  But since this is
the low-level SOAP API, I decided that it was inappropriate in this layer.  If
we can get a real error returning from the necko layers, then that is good.  But
there may well be SOAP calls which are not request / response.  The higher-level
proxy may also raise an error if the response is missing, if the lower layer
should have returned a response and did not.  But the transport layer must not
raise an exception for a missing response.
It should be noted that one way for the lower layers to communicate that an
error has occurred would be to deliver the error event.  The SOAP transport
could respond to this and translate it into an error.  But currently the error
event is not delivered in this case, and the SOAP handler of load and error does
not check to see which happened.
QA Contact: petersen → rakeshmishra
harishd is now the SOAP owner, reassigning.
Assignee: rayw → harishd
Status: ASSIGNED → NEW
Component: XML → Web Services
taking SOAP bugs
Assignee: harishd → jgaunt
Attached patch Patch which fixes the problem. (obsolete) — Splinter Review
I've run into this problem too. According to the documentation in
nsISOAPResponseListener.idl the 'status' argument of the completion callback is
supposed to contain an error code when the call fails at a low level. 

Attached is a patch which fixes the problem fills in the 'status' argument as
is documented. This error code can be used to display an error message to the
user.
My bad, I now see the comments about missing responses. The attached patch
expects a response, and generates an error when that's not the case. I'll take
that part out when I get a chance. 

IE: It should simply check the networking layers for errors when no response is
present, and if no error is present return a null response with no error code.
As promised, no accounts for empty responses.
Attachment #177207 - Attachment is obsolete: true
make that "now accounts for empty responses". BTW, any ideas on who should I ask
for review? This is my first patch in this component.
Attachment #177231 - Flags: review?(roc)
Attachment #177231 - Flags: superreview?(jst)
Attachment #177231 - Flags: review?(roc)
Attachment #177231 - Flags: review?(doronr)
Comment on attachment 177231 [details] [diff] [review]
Patch which takes empty resposnes into account

>+
>+    if(mResponse == NULL && NS_SUCCEEDED(rv)) {
>+
>+      // Get ahold of the XMLHttpRequest object
>+      nsCOMPtr<nsIDOMEventTarget> target;
>+      rv = aEvent->GetTarget(getter_AddRefs(target));
>+      if (NS_SUCCEEDED(rv) && target) {
>+        nsCOMPtr<nsIXMLHttpRequest> xrequest = do_QueryInterface(target, &rv);
>+        if (NS_SUCCEEDED(rv) && xrequest) {
>+
>+          // Now dig out the request from the channel
>+          nsCOMPtr<nsIChannel> channel;
>+          rv = xrequest->GetChannel(getter_AddRefs(channel));
>+          if (NS_SUCCEEDED(rv) && channel) {
>+            nsCOMPtr<nsIRequest> request = do_QueryInterface(channel, &rv);
>+            if (NS_SUCCEEDED(rv) && request) 
>+              request->GetStatus(&rv);
>+          }
>+        }
>+      }
>+    }

if(mResponse == NULL && NS_SUCCEEDED(rv)) { and friends:

I think just doing a if (mResponse) check should be enough here, but I might be
wrong :)

Other than that, looks fine.  I assume you testing working web services with
this patch?
Attachment #177231 - Flags: review?(doronr) → review+
Some SOAP calls are allowed to return success without a SOAP response. This
represents a one way function call without a return value. So just checking
mResponse is not enough. 

Yup works wonderfully, errors like 'host not found', or 'connection refused' are
now found in the 'status' argument to nsISOAPResponseListener::handleResponse.

Comment on attachment 177231 [details] [diff] [review]
Patch which takes empty resposnes into account

sr=jst
Attachment #177231 - Flags: superreview?(jst) → superreview+
Doron would you have time to commit the patch and close this bug? I don't have
CVS access. 
Assignee: mozilla → doronr
I'm willing to check this in, if we can find some soap tests that I can test
against. I'm using the text checked in and it doesn't appear that they exist
anymore.
QA Contact: rakeshmishra → web-services
We dropped SOAP.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: