From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010628 BuildID: 20010628 The above page http://fury.cdt.luth.se:7676/about/ issues an HTTP redirect to a different page but ommits the final CR-LF pair. This cause mozilla to show "<html><body></body></html>" in the HTML window Reproducible: Always Steps to Reproduce: 1. go to http://fury.cdt.luth.se:7676/about/ Actual Results: the renderer component displays <html><body></body></html> Expected Results: Either Mozilla (like IE, NS4.08, lynx) asuems the extra CR-LF is present and supports the redirect or a page explaining the error is displayed. output from server is: > telnet fury 7676 Trying 184.108.40.206... Connected to fury.cdt.luth.se. Escape character is '^]'. GET /about HTTP/1.0 HTTP/1.0 302 302 Date: Mon, 02 Jul 2001 13:35:49 GMT Server: cHTTPd/0.1 Java 1.2fcs/SunOS/5.7/sparc James Nord Location: http://www.cdt.luth.se/%7Enord/progs/mPing/ Connection closed by foreign host.
confirmed with win95 using 2001070108
17 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 89167 has been marked as a duplicate of this bug. ***
Updating summary. From the dupe, this breaks ford.com. I can't find anything in the specs to allow this, and the grammar does disallow it, so I'm 99% sure that its a server bug. I have no idea why we're displaying text for about:blank - probably something to do with the lack of a content-type header. Technically, we have no way of knowing that the server didn't just drop the connection in the middle, but I suppose we could special case redirections where the connection drops at the end of a header, if we already have the Location:. I can't see how this can ever work if the server supports keep-alives, without waiting for the server to give up and drop teh connection. ns4 manages though... ccing gagan/dougt for ideas. I'll have to think about this.
Summary: Mozilla gives strange feedback on invalid HTTP responses → redirection with no final \r\n not processed
I agree it's a bug in the server software but the way mozilla handles the error is IMHO wrong.
-> gagan to reassign/look into next week
I can not get to the Citibank credit card site where payments are made, statements are viewed, etc. http://www.accountonline.com/ (which is redirected to https://www.accountonline.com/CB/Login.jsp) I simply get, <html><body></body></html>, as seems to be the symptom of problems tied to this bug. I also can not get to https://login.yahoo.com/ I consider these sites to be top priority for consumers, and they work fine with IE as well as under some earlier versions of mozilla.
Assignee: gagan → darin
This is not a problem on the Solaris 2001073123 build (trunk). It is still a problem on the windows 2001073103 build
Priority: -- → P2
Target Milestone: mozilla1.0 → mozilla0.9.4
not seeing this with my linux 2001-08-01/04 0.9.3 branch build.
i take it back, i am seeing this problem with the original reported link: http://fury.cdt.luth.se:7676/about/ changing Platform:OS to All:All
OS: Windows NT → All
Hardware: PC → All
This means that we'll never get an error if the server drops the connection before finishing writing out the headers. This is probably OK, though. r=bbaetz
Whiteboard: r=bbaetz, sr=? → r=bbaetz, sr=dougt
Whiteboard: r=bbaetz, sr=dougt → r=bbaetz, sr=dougt, fixed-on-trunk
As of the Windows 2001080303 trunk build I cannot get to any secure sites. I enter the URL in the URL bar, the throbber throbs, stops throbbing and nothing changes. The previously displayed page is still there. http://www.accountonline.com/ -> https://www.accountonline.com/CB/Login.jsp https://login.yahoo.com/ visa.yahoo.com etc...
checked original url and Tom's additional urls. All seem to be working on the trunk. Older builds were failing as described. verified on trunk: win NT4 2001080804 Linux rh6 2001080810 Mac os9 2001080810
qa -> me
QA Contact: benc → tever
Whiteboard: r=bbaetz, sr=dougt, fixed-on-trunk → r=bbaetz, sr=dougt, verified-on-trunk
let's get it on 0.9.2 branch
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.