First, verify that you have a functional SOAP call example, by loading /mozilla/extensions/xmlextras/tests/soapisprimenumber.html and pressing the button after typing numbers to verify it works. Now, to to the line "s.transportURI = http://ray.dsl.xmission.com:8080 ... and change it so that it is an address that is not known, such as ray.dsl.xmission.commmmm. I did this by just adding extra m's on the .com and leaving the rest of the line the way it was. Now, when you invoke the SOAP call, no completion is ever reported, either error or successful. At the very least, this is a resource leak every time a bad address is accessed, but it seems worse than that for those trying to rely on the SOAP interfaces. After discussions with Heikki, I believe this is a problem with netlib, which must be fixed there if it can be fixed. We really need a completion in this case to tell us what happened to our call, even if we have to manufacture an error timeout. Examine nsHTTPSOAPTransport.cpp and I think you will find that AsyncCall passes back any failure it gets, as does HandleEvent on the completion object and the reason nothing happens is because the net library gives us nothing.
Forgot to assign SOAP bug to self.
Assignee: heikki → rayw
This can be very annoying since the status of a web site becoming unavailable can cause web pages to behave badly. It might be possible to track down the source of this bug and fix it in mozilla 0.9.9. It at least deserves some effort. Marking 0.9.9 and nominating nsbeta1. I do not have a fix yet, so as a fix is discovered, this nomination might be reevaluated.
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla0.9.9
Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+, topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword. Please send any questions or feedback about this to firstname.lastname@example.org. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla0.9.9 → mozilla1.2
My latest attempts to duplicate this bug show that the calls do complete, but with a null result, so this is a duplicate of bug 126210. *** This bug has been marked as a duplicate of 126210 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.