With a non-existant web addresses, SOAP calls do not complete.

RESOLVED DUPLICATE of bug 126210

Status

()

P2
normal
RESOLVED DUPLICATE of bug 126210
17 years ago
16 years ago

People

(Reporter: rayw, Assigned: rayw)

Tracking

Trunk
mozilla1.2alpha
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

17 years ago
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.
(Assignee)

Comment 1

17 years ago
Forgot to assign SOAP bug to self.
Assignee: heikki → rayw
(Assignee)

Comment 2

17 years ago
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
Keywords: nsbeta1
Priority: -- → P2
Target Milestone: --- → mozilla0.9.9
(Assignee)

Comment 3

17 years ago
Removing nsbeta1.
Keywords: nsbeta1
(Assignee)

Updated

17 years ago
OS: Linux → All
Hardware: PC → All

Comment 4

17 years ago
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 adt@netscape.com.  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.
Target Milestone: mozilla0.9.9 → mozilla1.2
(Assignee)

Comment 5

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

Updated

16 years ago
QA Contact: petersen → rakeshmishra
You need to log in before you can comment on or make changes to this bug.