User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20030118 Phoenix/0.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20030118 Phoenix/0.5 Whenever you click on links on http://www.yahoo.com that redirect you with the http://rd.yahoo.com, you constantly get the message pop up saying "The connection was refused when attempting to contact rd.yahoo.com". Redirections on yahoo do not work correctly on yahoo. For instance, I am going to my geocities site, when I click on the "File Manager" in the Advanced toolbox (whose url is "http://rd.yahoo.com/geohome/m/*http://geocities.yahoo.com/v/fm.html"), I get the message. Reproducible: Always Steps to Reproduce: 1.go to geocities.yahoo.com 2.log in 3.click on file manager in the advanced toolbox 4.see the message Actual Results: Got the message "The connection was refused when attempting to contact rd.yahoo.com" Expected Results: It should have redirected me to the page that has the file manager on it.

WFM 2002121217 Linux... This happen under IE too? [hosts file problem? DNS?]

Marking invalid - confirmed with Yahoo that a mail server farm is down.

What does a mail server have to do with web pages??? It happens on a LOT of their web pages.

Reopening, this isn't a mail server problem. I have been seeing this for a while and still am with the latest MozillaTrunk builds. I'm using build 2003021008 (Mozilla 1.3 Beta)...and when clicking on a link from my yahoo: http://rd.yahoo.com/mymod/groups/*http://groups.yahoo.com/mygroups I get an Alert that says "The document contains no data". Darin: Is this a problem with parsing the URL? Or is it something on Yahoo's side? A lot of links on yahoo.com are pretty much useless b/c of this redirecting problem. I have to copy the link url and cut off the "rd.yahoo.com/----/*" to go anywhere!

And to answer the question in comment #1, yes...this also seems to be a problem with IE. Trying to click on the same link from my last comment, I get the "The page cannot be displayed" message on IE. Either both browsers are having trouble dealing with the redirect URL or yahoo.com just needs to get their servers working correctly.

Setting component to Networking, please correct me if I'm wrong and reassing. Thanks.

jpatel: i'm not able to repro this bug. can you capture a HTTP log for me? make sure these environment variables are set before running mozilla: NSPR_LOG_MODULES=nsHttp:5 NSPR_LOG_FILE=c:\http.log you don't need a debug build for this. thx!

Steps taken (and catured in http.log): 1. start browser 2. goto my homepage (already set to my.yahoo.com) 3. click on my groups link (http://rd.yahoo.com/mymod/groups/*http://groups.yahoo.com/mygroups) 4. dismiss alert popup 5. click on ftd.com link (http://rd.yahoo.com/M=229633.2926357.4268643.1864670/D=my/P=m2d2stc411ae0400/S=150000251:C1/A=1428263/R=0/*http://shop.store.yahoo.com/cgi-bin/clink?ftd2+shopping:dmad/M=229633.2926357.4268643.1864670/D=my/P=m2d2stc411ae0400/S=150000251:C1/A=1428263/R=1/1045006213+http://us.rmi.yahoo.com/rmi/http://www.ftd.com/rmi-framed-url/http://www.ftd.com/yahoo1) 6. dismiss alert popup 7. shutdown browser

OK, i spent some time debugging this on jpatel's system. turns out that i must not try to handle the PR_Poll out_flags during a connection attempt myself. instead i should call PR_ConnectContinue so it can properly map error conditions to error codes. when this is done, the error changes from "the document contains no data" to the "connection was refused". this is consistent with N7.01 and IE6. however, i don't think this is any problem with the server. instead, it seems like a problem with WinXP on Jay's machine because a packet trace didn't reveal any connection attempt being made by WinXP. the NSPR error code is -5981 (or PR_CONNECT_REFUSED_ERROR), but that just seems wrong. Jay's other WinXP machine has no trouble loading these links. attaching a patch that restores our old behavior (i.e., report this as a conneciton refused error instead).

-> me (for 1.3 final)

*** Bug 192822 has been marked as a duplicate of this bug. ***

Comment on attachment 114153 [details] [diff] [review] v1 patch (with whitespace changes removed) sr=bzbarsky if wtc blesses this.

What is the value of PR_GetOSError() when PR_ConnectContinue() fails?

Comment on attachment 114153 [details] [diff] [review] v1 patch (with whitespace changes removed) Darin, I'm not really qualified to review this patch because I'm not familiar with Necko. In particular I can't review the changes to nsSocketTransport::OnSocketReady related to "if (mState == STATE_TRANSFERRING)". The other changes in this patch look fine to me. If you want me to review this patch, I'll need you to sit down with me so that I can get my questions answered in real time.

*** Bug 192825 has been marked as a duplicate of this bug. ***

I had this problem too, and it was because an entry redirecting rd.yahoo.com to 127.0.0.1 was inserted in my hosts file upon installation of Kazaa Lite. Commenting out the lines with rd.yahoo.com in my hosts file (C:\Windows\System32\Drivers\etc\hosts I think) fixed the problem.

Misha's suggestion worked for me! There were about 5 lines in my hosts file for rd.yahoo.com. After removing those lines, the links are working fine. Thanks!

*** Bug 192977 has been marked as a duplicate of this bug. ***

*** Bug 191534 has been marked as a duplicate of this bug. ***

*** Bug 193092 has been marked as a duplicate of this bug. ***

I would strongly recommend to change the summary of this bug since both the summary and the description are misleading. This will probably sparc a lot of DUPes since it is a recent regression that also is 1.3b. It seems bug 193092 more accurately describes what this bug is about.

If you go into the HOSTS file in the c:\windows\system32\drivers\etc folder and delete all the rd.yahoo.com entries (plus any of the other porn sites or other garbage sites that send you spam) you can resolve this problem successfully.

*** Bug 193154 has been marked as a duplicate of this bug. ***

I guess I don't understand why my <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=193154">bug 193154</a> is a duplicate of this. This is not some unintentional ability to get to web pages thanks to unwanted entries in a hosts file. This is Mozilla giving error messages when none are warranted. Several of the other bugs that were marked as dupes seem to be about the same thing. If someone has decided that this particular use of the hosts file is not going to be appropriately accomodated by Mozilla so be it, but it's annoying to see the issue totally misunderstood or ignored by the arbiters of bug tracking. :-) When you try the pages in question in IE, you get an "action cancelled" message printed in the area the iframe was supposed to take up. That's fine; I don't mind some sort of visual feedback that a banner was blocked, but an error message that requires user interaction is a real pain and that's what Mozilla does. I'd also like to point out that this is an example of inconsistent behavior from Mozilla. As my bug noted, if a simple img tag is blocked because of the hosts file, you get no error. Why should it be different just because the content is in an iframe? Not trying to be an ungrateful pain in the @$$ or anything, but this really seems like something that should be fixed, not forgotten.

jay: If you have those entries in your hosts file, and you use the fixed version, do you get the correct error? darin: Please change the summary so it describes the behavior you changed. Normally I would do this, but I'm not sure how to describe it, perhaps: "PR_Poll out_flags should call PR_ConnectContinue" (I have no idea what I just wrote). Also, I'm confused about the nature of the problem. Does windows hand back different errors for connection failure via DNS vs. hosts? I'm not sure I understand why removing the hosts entries caused the errors to come back correctly. People who use hosts file entries w/o good reason (or remembering what entries are in that file) are often looking for trouble. Also, if this bug+fix turns out to be very low-level and not obviously related to the other places where "document contains no data" errors began appearing, I'm going to reopen those bugs, mark them as depends, because I need to verify each of them separately anyhow.

As Matt has said, this is more than one bug. by bug (http://bugzilla.mozilla.org/show_bug.cgi?id=192977)was also marked as a duplicate of this one, but the problem is very different. My bug is identical to the one reported by Matt (http://bugzilla.mozilla.org/show_bug.cgi?id=193154), getting an error message when none is warranted. This is related to using the hosts file for banner blocking.

This was a bug report about a problem I had. I have fixed MY problem. I want this to be closed off so that I receive no more emails about it. It has started to be a pain in my butt. If you have any more problems concerning this, please post it to another bug report and post it there so that this one can be closed to further posts. Thanks, Steve

reopening. the patch has not landed. the fact that this bug showed up because of the bad "hosts" file does not mean that this is fixed. the problem is much deeper, as the number of dupes demonstrates. the core problem is that we are treating any connection error as a TCP RST, and that is wrong. the patch fixes this.

ben: i worked with darin on this, and from what i observed: 1. using trunk build 2003021008, with the rd.yahoo.com lines in my hosts file, i was getting the "document contains no data" message...which is wrong. 2. using darins's debug build with his patch, with the rd.yahoo.com lines in my hosts file, i was getting the "connection refused when attempting to contact..." message...which i believe is correct. 3. using either build, without the rd.yahoo.com lines in my hosts file, the links i clicked on were working just fine.

Comment on attachment 114153 [details] [diff] [review] v1 patch (with whitespace changes removed) r=wtc.

fixed-on-trunk

*** Bug 193407 has been marked as a duplicate of this bug. ***

If my bug 193092 is a DUP of this bug, then I do not understand, why the message "the document contains no data" still occurs in the 20030214/linux build when a the proxy cannot be reached. Also, as I reported in that bug, not *all* connection errors showed this error, but only errors due to non-existing proxies, when the preferences specify to use a proxy.

*** Bug 193468 has been marked as a duplicate of this bug. ***

Recommend REOPEN. NOT FIXED for XPI downloads. Steps to reproduce: 1. add: 127.0.0.1 downloads.mozdev.org to your HOSTS file to simulate connection refused error. 2. Attempt to download any XPI file. (example: http://downloads.mozdev.org/optimoz/mozgest_0_3_5rc2.xpi) 3. Watch the Alert. (results: The Document Contains No Data) should be: Connection refused.

ok, this patch only solved the problem on windows. sorry!! seems i didn't test carefully enough on linux. bug 193267 contains a fix that should do the trick for linux.

*** Bug 193624 has been marked as a duplicate of this bug. ***

I just install the trunk build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030218. There is still problem while using proxy server, proxy.hinet.net port:80. But this time the alert message is "The operation time out when attempting to contact ...."

Yeh You-Ying: are you able to use that proxy server with other browser?

Hello Darin Fisher, Yes, I can use IE here. With the same proxy server (proxy.hinet.net port:80) setting in IE6, there is no problem while accessing websites.

For reference, Yeh You-Ying's bug is filed as bug 192836.

*** Bug 192813 has been marked as a duplicate of this bug. ***

*** Bug 194497 has been marked as a duplicate of this bug. ***

*** Bug 194497 has been marked as a duplicate of this bug. ***

*** Bug 194716 has been marked as a duplicate of this bug. ***

*** Bug 195561 has been marked as a duplicate of this bug. ***

Is this bug present in 1.3b?

yes, it's in 1.3b

*** Bug 196741 has been marked as a duplicate of this bug. ***

*** Bug 197109 has been marked as a duplicate of this bug. ***

VERIFIED/fixed: Mozilla 1.3f I've gone through all the duplicates, and cleaned them up (corrected component, -> VERIFIED). The ad blocking stuff, we'll I don't consider it legitmate, so I just let those be marked duplicate, because that was the original problem here. Some bugs were test results or described a specific problem, and I marked those as depends, because this bug hit so many areas, and I verified them independently, to make sure they work. In some cases, people described dialogs where stuff pops up when I did not think it should. There might be some usages of RSET that I am unaware of, so I made a note that they should reopen if 1.3f still has the problem. Interestingly, I think this bug was actually Windows-only, there were no Mac or Linux reports.

*** Bug 199480 has been marked as a duplicate of this bug. ***

Using Mozilla 1.3 release, if I try to load a web page when my dial-up connection has dropped, I get no error at all, which isn't as irritating as 'the document contained no data' but still serves to confuse temporarily. Maybe taking a very small page out of IE's book might be an idea - instead of popping an error message, show a page with the message on it. Just write something useful on it, not IE's wonderful "the page could not be displayed" and insertion of random incorrect reason :-) IMO, the error descriptions should be (and a link to the URL the user attempted to access, underneath the error message, to allow them to click on it again for convenience value): Situation: the server responded with 'connection refused' Error msg: "Connection refused: The server may be down at the moment." Situation: Unable to resolve the domain name Error msg: "Domain name resolution failed: If you are experiencing difficulties contacting any websites, this problem could be with your ISP or your Internet connection has failed." Situation: the server responded [negatively] with a useful error number Error msg: the error should reflect the particular error number, be it from http/s or ftp. I can't think of any other useful situations/responses at the moment, and other people with better knowledge of all the possible error-producing situations might come up with better error message/descriptions than I have done, but there's my 2 cents worth.