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)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: rayw, Assigned: doronr)
References
Details
Attachments
(2 files, 1 obsolete file)
3.87 KB,
text/html
|
Details | |
1.94 KB,
patch
|
doronr
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•22 years ago
|
||
Here is a test case given me by a user who modified soapcall.html which produces the problem (at least today it does).
Updated•22 years ago
|
Priority: -- → P3
Reporter | ||
Updated•22 years ago
|
Status: NEW → ASSIGNED
Reporter | ||
Updated•22 years ago
|
Hardware: Other → All
Reporter | ||
Comment 2•22 years ago
|
||
*** Bug 123506 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 3•22 years ago
|
||
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.
Reporter | ||
Comment 4•22 years ago
|
||
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.
Updated•22 years ago
|
QA Contact: petersen → rakeshmishra
harishd is now the SOAP owner, reassigning.
Assignee: rayw → harishd
Status: ASSIGNED → NEW
Updated•21 years ago
|
Component: XML → Web Services
Comment 7•19 years ago
|
||
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.
Comment 8•19 years ago
|
||
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.
Comment 9•19 years ago
|
||
As promised, no accounts for empty responses.
Attachment #177207 -
Attachment is obsolete: true
Comment 10•19 years ago
|
||
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.
Updated•19 years ago
|
Attachment #177231 -
Flags: review?(roc)
Updated•19 years ago
|
Attachment #177231 -
Flags: superreview?(jst)
Attachment #177231 -
Flags: review?(roc)
Attachment #177231 -
Flags: review?(doronr)
Assignee | ||
Comment 11•19 years ago
|
||
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+
Comment 12•19 years ago
|
||
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 13•19 years ago
|
||
Comment on attachment 177231 [details] [diff] [review] Patch which takes empty resposnes into account sr=jst
Attachment #177231 -
Flags: superreview?(jst) → superreview+
Comment 14•19 years ago
|
||
Doron would you have time to commit the patch and close this bug? I don't have CVS access.
Assignee | ||
Updated•19 years ago
|
Assignee: mozilla → doronr
Comment 15•19 years ago
|
||
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.
Updated•15 years ago
|
QA Contact: rakeshmishra → web-services
We dropped SOAP.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
Updated•7 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•