Closed Bug 219150 Opened 21 years ago Closed 21 years ago

Failed connections stall instead of giving Connection Failure Error (sites with scripts from ad hosts don't load completely if ad hosts are set to 127.0.0.1)

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED DUPLICATE of bug 219376
Milestone:
mozilla1.6alpha

People

(Reporter: jruderman, Assigned: darin.moz)

References

Details

(Keywords: regression) 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030913
Firebird/0.6.1+

Steps to reproduce:
1. Try to load http://127.0.0.1/ from the address bar.

Expected: "Connection Failure Error" error page.

Result: Throbber keeps spinning, status bar says "Connecting to 127.0.0.1...",
error page does not load.

Why this is major: This bug also affects SCRIPT objects.  Many users "block" ads
by setting ad hosts to 127.0.0.1 in their hosts sites.  For these users, sites
with <script src="http://ad.doubleclick.net/showAdHere.js"></script> don't
display completely because the script load stalls instead of failing quickly. 
(Reported at http://forums.mozillazine.org/viewtopic.php?t=24689#192636 against
http://www.winfuture.de/ , http://www.zdnet.de/ , http://www.kicker.de .)

This is a regression in 09/12 builds of Seamonkey and Firebird.  09/11 builds of
both worked correctly.
Sounds like the retry logic for refused connections is hosed.
It would appear this is probably caused by the code for bug 205726.
This appears to happen on both connection timeout errors as well as connection
refused.  In either case it appears to just try forever.
Flags: blocking1.6a+
don't use flasg if you don't know what they mean
Flags: blocking1.6a+
WFM Firebird 20030912:

1. Open firebird
2. Type 127.0.0.1 in URL bar and press enter
3. "The connection was refused when attempting to contact 127.0.0.1"

Am I missing something?
I am sure this build has the DNS rewrite code because IPv6 works.
OK.  Firstly this is not just a 127.0.0.1 issue.  THe same problem will occur
sith a perfectly legit URL if the server is not accepting conections for some
reason.

Secondly, I have done some testing on this with a sniffer on the network.  Here
is what I found.

The conenction retry logic actyually does appear to be working as it should.  If
there is only one address it tries to connect 3 times.  If there is more than
one address it tries 3 times for each address.  So It is not (as I had feared)
attempting to connect continuously.  This would have been a very bad things as
it would ahve set off alarms on most Intrusion Detection Systems.  So this is
still a serious issue, but at least we won't have users getting calls from their
ISPs asking them not to run Mozilla Firebird.

So it appears that it is doing the corret retries, it is just that when the
retries get used up it is not behaving correctly.
Re comment #5.  Are you using Windows?  This could be a windows only issue. 
There is code under a windows ifdef that tries to make dialup connections if it
can't connect.  The hang could be occuring withing this section of code.  My
personal opinion is that this code should be removed because recent versions of
Windows will have alrady tried a dialup connection before getting to this point
under a user condifugrable network option.
Yes, I am using Windows XP.
But I don't use dialup connections because I'm behind a router.
Summary: URLs with no server stall instead of giving Connection Failure Error (sites with scripts from ad hosts don't load completely if ad hosts are set to 127.0.0.1) → Failed connections stall instead of giving Connection Failure Error (sites with scripts from ad hosts don't load completely if ad hosts are set to 127.0.0.1)
Well tht makes liitle or no sense, I am running Windows XP as well and I have
this problem even if I am connected via dial-up.

Do you have any dial-up connections installed at all?  If not perhaps that is
the difference?
This bug has the following effects:

* If a site is down or doesn't resolve, the browser appears to be waiting for
the site when it could have given a useful error message.

* Typing "scrippscol.edu" (without www) into the address bar no longer gets you
to http://www.scrippscol.edu/ .

* If you use a hosts file to block ads, many sites don't load completely.  (You
can't see all the non-ad content on those sites.)
Blocks: 219390
Re comment #4.

I was trying to set this bug a blocker to the next release, which as near as I
could tell would be 1.6a.

1.  If setting the blocking 1.6a is not the correct way to do this then what is?

2.  If you think the next release should go out with a bug a serious as this in
it you are brain-damaged.

3.  If it is too early to set bugs as blocking 1.6a, then the choice should not
exist.

4.  If only certian people should be marking bugs as blocking and I am not one
of them then my bugzilla account should not have the priviledge to set this flag.

Just my opionion, I could be wrong.
> 1.  If setting the blocking 1.6a is not the correct way to do this then what is?

The correct thing is to nominate it as a blocker by setting the blocking1.6a
flag to "?".

> 2.  If you think the next release should go out with a bug a serious as this
in it you are brain-damaged.

This isn't that serious - the browser is still quite usable.  Alpha releases
usually go out with bugs.  However, I agree that this should be fixed, and I'm
setting the flag to "?".

> 4.  If only certian people should be marking bugs as blocking and I am not one
of them then my bugzilla account should not have the priviledge to set this flag.

That is true and there is a bug open for fixing that.  However, it is hoped that
most people won't change things without understanding them.  If they do, then
people can tell them how it is supposed to work and change it back (as in
comment 4).
Flags: blocking1.6a?
re comment #12.  Thank you.  Very good explanation.  SO I was supposed to have
set it to a ? and not a +.  I wihsh the person who turned it off would have told
me that instead of basically being of no help at all.
Re comment #12:

> This isn't that serious - the browser is still quite usable.  Alpha releases
> usually go out with bugs.  However, I agree that this should be fixed, and I'm
> setting the flag to "?".

At the time I was orginally trying to set this a s a blocker the bug was thought
to be more serious.  Up until the time I put a sniffer on the network to see
what was actually hapening it was though that the browser was retrying
connections indefinitely on a connection refused condition.

I agree the browser is quite usable and works just fine unless there is some
kind of networking issue or webserver issue and things are down in which case it
kind of just hangs.  Another problem is that this bug can mask other issues
becuase if Firebird now hangs for any reason whatsoever, we couls easily be
fooled into thinking it is just this bug.

Also, since I have been using firebird nightlies since mid July, this is the
only bug that given if the only 2 browsers that were availbel to me were IE and
a Firebird browser with this bug, I would use IE as my default browser.  That is
the major reason I would not suggest any release (even alpha) go out with this bug.
Oh dear.  This issue has just been made worse by a combination of action by
Verisign and some ISPs.  Verisign has launched a new "service" they call Site
selector.  To implement this they have abused their posion of managing the top
level net and com domains and have added wildcard A records to both pointing to
a server that they control so that they can present a hey you can buy this
domain from us, or maybe you typed it wrong and wanted to go to xyz.org not
xyz.com, etc. site complete with ads etc.  See:

http://www.wired.com/news/technology/0,1282,60473,00.html

for some background on this.

Well, now in addition to the DNS block efforts, some ISPs are blocking port 80
access to the IP address 64.94.110.11 (which is the address the wildcard A
record points to).

So now if you misstype a URL which should end up just getting a no such host
error becuase it is not in DNS, DNS returns the 64.94.110.11 address which your
ISP is likely to be blocking so you end up running into this Firebird hang issue
even more often than you would have normally.  ... sigh :-(


 
William A. Gianopoulos wrote:
> Well, now in addition to the DNS block efforts, some ISPs are blocking port 80
> access to the IP address 64.94.110.11 (which is the address the wildcard A
> record points to).

According to the Wired article, the block affects the BIND software that is used 
by approximately 80% of the Internet's domain servers. It seems that "Some
ISP's" is an understatement. :(
i can reproduce this on using the 20030916 trunk seamonkey build under linux (rh9)
Status: NEW → ASSIGNED
OS: Windows XP → All
Target Milestone: --- → mozilla1.6alpha
Re: commnet #17.  So much for the story that this is a windows only bug.
*** Bug 219703 has been marked as a duplicate of this bug. ***
This is listed as a browser bug.  Should it not be an NSPR bug?
Hmmm. Looking more closely at at he components decription, it should probably be
a netlib bug but that does not appear to be a choice.  My point is that this is
listed as a browser bug, but my guess is that it effects mail/news as well, but
you would never guess that or find it searching in Bugzilla.  What is the proper
thing to put for the product designation on a bug in the netwokring code that
effects all components?
*** Bug 219945 has been marked as a duplicate of this bug. ***
*** Bug 220206 has been marked as a duplicate of this bug. ***
*** Bug 220323 has been marked as a duplicate of this bug. ***
i think the patch for bug 219376 may help with this...
Depends on: 219376
From http://forums.mozillazine.org/viewtopic.php?p=207315 : Kazaa Lite creates
an ad-blocking hosts file.  Not all Kazaa Lite users know that they have a hosts
file.
In answer to comment #26 I had Kazaa Lite, but have removed it from my system
around a month ago. Also removed last traces of it with Adaware and Spybot. I
can assure that is not why I am stuck on Mozilla 20030904.


elst93@wxs.nl: you're also using a bug from before this regression was introduced :)
I am using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6a)
Gecko/20030927 at this moment. When my HOSTS file contains advertisement
blocking links, Mozilla Seamonkey still refuses to load sites fully (stuck at
99% loading bar). I now cleared my HOSTS file of the ad-blockers, logged off and
back on and am now able to go to those pages I wasn't able to get to. 

For now I'll live with the popup blocker and blocking images. 
*** Bug 220503 has been marked as a duplicate of this bug. ***
Flags: blocking1.5+
por@xs4all.nl: You have to request flags by setting "?".  Only Asa and a few
other people may set "+".  Also, this bug doesn't affect the 1.5 branch :)
Flags: blocking1.5+
*** Bug 220971 has been marked as a duplicate of this bug. ***
*** Bug 220440 has been marked as a duplicate of this bug. ***
*** Bug 221375 has been marked as a duplicate of this bug. ***
dup

*** This bug has been marked as a duplicate of 219376 ***
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
all the dupes and votes are on this earlier bug, but there's a patch on that
one, so I guess it has to be duped this way...

verified
Status: RESOLVED → VERIFIED
No longer depends on: 219376
Flags: blocking1.6a?
*** Bug 222490 has been marked as a duplicate of this bug. ***
REOEPEN:
Was this problem fixed by fixing bug 219376? That doesn't make this problem a
dupe, in an imperfect world of patches fixing more than one bug, it should be
recorded as a depends.

I'm also removing the blocks on 219150. This bug would have blocked all Domain
Guessing, but that bug was just a Domain Guessing RFE.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
(correction: removing depends on bug 219390...) adding depends for bug 219464
(problems caused by site minder)
No longer blocks: 219390
Depends on: 219464
i don't think this has anything to do with the Verisign NXDOMAIN crap!  this was
a regression from the DNS resolver rewrite.  it is just another symptom of the
same underlying problem that was fixed by my patch for bug 219376.

i think bienvenu was correct in marking this a duplicate of that bug.  though
the descriptions might sound different, these two bugs are very much one and the
same.

*** This bug has been marked as a duplicate of 219376 ***
Status: REOPENED → RESOLVED
Closed: 21 years ago → 21 years ago
No longer depends on: 219464
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.