Closed
Bug 97997
Opened 23 years ago
Closed 23 years ago
easyweb.tdcanadatrust.com does not display
Categories
(Core :: Networking: HTTP, defect, P1)
Core
Networking: HTTP
Tracking
()
RESOLVED
FIXED
mozilla0.9.4
People
(Reporter: chrisa, Assigned: darin.moz)
References
()
Details
(Whiteboard: fixed-on-trunk,PDT+)
Attachments
(5 files, 1 obsolete file)
36.25 KB,
text/plain
|
Details | |
26.19 KB,
text/plain
|
Details | |
98.72 KB,
text/plain
|
Details | |
61.90 KB,
text/plain
|
Details | |
7.54 KB,
patch
|
darin.moz
:
review+
darin.moz
:
superreview+
|
Details | Diff | Splinter Review |
Attempted to log in to TD EasyWeb from www.tdcanadatrust.com followed by Login Now under EasyWeb. Browser shows busy and appears to be loading page. Finally, the status bar shows Complete, the address bar shows https://easyweb.tdcanadatrust.com/, but no page is displayed. (mozilla version 20010831)
Comment 1•23 years ago
|
||
worskforme, linux build 2001-08-31-08 This site used to exhibit those symptoms (bug 71595), but that has been fixed since June... Please retest?
Comment 2•23 years ago
|
||
Confirmed, 2001-08-31-03 on Windows 98 SE. It is the frame https://easyweb47.tdcanadatrust.com/main.jsp?lang=english&fromIndex=true that does not display. Doing "view -> Page Source" shows: <html><body></body></html> If I save the page with IE and then load that into Mozilla it looks fine. Could for example be a https problem or a browser sniffer problem at the site.
Severity: critical → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•23 years ago
|
||
Over to PSM for now... This works fine on Linux, so it's not an evang bug anymore....
Assignee: asa → ssaux
Component: Browser-General → Client Library
Product: Browser → PSM
QA Contact: doronr → bsharma
Version: other → 2.1
Comment 4•23 years ago
|
||
P1, t->2.1 rangansen
Assignee: ssaux → rangansen
Priority: -- → P1
Target Milestone: --- → 2.1
Updated•23 years ago
|
Keywords: nsenterprise
Comment 5•23 years ago
|
||
Using Linux Build ID : 2001090408, I can reproduce the problem. Therefore I'm not sure this is a PSM bug.
Reporter | ||
Comment 7•23 years ago
|
||
I just tried the ING Direct (Canada) website using build 2001090408 and noticed two things 1) the main screen (www.ingdirect.ca) does not display the banner graphics properly - the picture is rendered to the left of its associated text. This displays properly in IE and Netscape 4.7x 2) More to the point, https://secure.ingdirect.ca/InitialINGDirect.html?command=displayLogin&device=we b&locale=en_CA does not display anything. Looks like an https problem...
Comment 8•23 years ago
|
||
When frame https://easyweb47.tdcanadatrust.com/main.jsp?lang=english&fromIndex=true is requested, the https connection goes through fine, but the read/write request [netwrek/base/src/nsSocketTransport, function nsSocketTransport::doReadWrite] returns NS_BASE_STREAM_WOULD_BLOCK status, and finally no data is read in - Is this a trouble in the netwrek code ? Adding darin to the cc list... Darin can we have your comments on this issue?
Assignee | ||
Comment 9•23 years ago
|
||
as boris mentioned, this doesn't seem to be a problem under linux... testing winnt (i don't have a win2k box handy).
Assignee | ||
Comment 10•23 years ago
|
||
i'm able to reproduce this problem in a 8/31 winnt build. investigating...
Assignee | ||
Comment 11•23 years ago
|
||
ugh.. i'm having trouble getting a PSM win32 build.. will get back to this later.
Assignee | ||
Comment 12•23 years ago
|
||
rangan: it would be helpful if you could generate a socket transport log and attach it to this bug.
Comment 13•23 years ago
|
||
Comment 14•23 years ago
|
||
I get the same behaviour under Windows 2000 at url https://easyweb.tdcanadatrust.com/ . In particular, using build 2001082703 it worked correctly. Switching to 2001090408 it did NOT work. Using 2001090603 it is still broken. So something changed between 08/27 and 09/04 (I dont have builds between these to narrow it down further).
Comment 15•23 years ago
|
||
Also, some relevant observation - When an attempt to connect to the server is made, the first two attemps always return with a PR_WOULD_BLOCK_ERROR [that is, socket blocks, which, I believe, is normal, for during the first one or two attempts response might on have arrived]. But the third attemp gets the following data: Content :HTTP/1.1 500 ok Date: Fri, 07 Sep 2001 21:23:23 GMT Server: IBM_HTTP_Server/1.3.6.2 Apache/1.3.7-dev (Unix) PICS-Label: (PICS-1.0 "http://www.rsac.org/ratingsv01.html" l by "tdinfo@tdbank.ca" on "2000.04.24T10:49-0400" exp "2001.04.24T12:00-0400" r (v 0 s 0 n 0 l 0)) Pragma: no-cache Connection: close Transfer-Encoding: chunked Content-Type: text/html 0 I am not too sure what this trailing 0 means - but the status code 500 at the top should mean an internal server error, which should not have anything to do with the client. But, then how come does this site work on some other browsers [Netscape 4.7, for example]. Also, after this point, no further reconnect attempt is made...
Comment 16•23 years ago
|
||
Here is the reason why this happens - With the present builds, the http request shows like: GET / HTTP/1.1 Host: easyweb.tdcanadatrust.com User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.2+) Gecko/20010719 Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9, image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css, */*;q=0.1 Accept-Language: en-us Accept-Encoding: gzip,deflate,compress,identity Accept-Charset: Connection: close Cookie: RMID=d00c3dd23b9bf610 The Accept-Charset field is totally blank. This hearder would be malformed and in some cases, generates error in the server. Enforcing the charset [in the tab edit->preferences->navigator->language] to (utf-8, *) for example, sets the proper value in the accept-charset field, and gets the thing working. A few more related points 1. IN the earlier builds, where this was working ok, the request-charset field used to have a value like ISO-8859-1, utf-8;q=0.66, *;q=0.66 2. I found this bug does not appear with classic skin, and also vanishes when we shuffle skins [like modern->classic->modern]. In these cases, somehow the request-charset field starts getting the correct value. The charset in the is languages tab is normally set to default. Darin, though this might actaully be a skin related problem, I am reassigning this bug to the networking module, because that is where these request parameters would be set and passed to psm as request strings.
Comment 17•23 years ago
|
||
Reassigning this bug, as per earlier comments
Assignee: rangansen → neeti
Component: Client Library → Networking: HTTP
Product: PSM → Browser
QA Contact: bsharma → tever
Target Milestone: 2.1 → M1
Version: 2.1 → other
Comment 18•23 years ago
|
||
adding Stephane to cc list
Comment 19•23 years ago
|
||
changing summary
Summary: Page does not display → easyweb.tdcanadatrust.com does not display
Reporter | ||
Comment 21•23 years ago
|
||
I attempted to use the work-around suggested by the post from Rangan Sen 2001-09-10 16:10 at home on my Win2K SP1 machine. It does not work with build 2001090904. I also noticed in his post the line User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.2+) Gecko/20010719 suggesting an earlier build (and the earlier builds did work). I tried last night's build at work (NT4 SP6a) and it also did not work.
Reporter | ||
Comment 22•23 years ago
|
||
Shoot me, please! Switching skins did not work, but setting the default character set did (build 2001090904, Win2K SP1)
Assignee | ||
Comment 23•23 years ago
|
||
-> me... there's a dup someplace of the missing Accept-Charset header bug.
Assignee: neeti → darin
Comment 24•23 years ago
|
||
Darin/Gagan - IS this gonna be fixed this round, or should we nsbranch- this bad boy?
Assignee | ||
Comment 25•23 years ago
|
||
-> 0.9.5 until i locate the dup
Status: NEW → ASSIGNED
Target Milestone: M1 → mozilla0.9.5
Assignee | ||
Comment 26•23 years ago
|
||
https://easyweb.tdcanadatrust.com/ fails to load for me using the 2001-09-12/08 linux trunk build, and setting the charset pref to UTF-8 makes the page load. when requesting any HTTP url, using a packet sniffer i am seeing a valid Accept-Charset header... not a blank header. reporter: how did you determine that mozilla is sending a blank Accept-Charset header? could this simply be an evangelism bug?
Assignee | ||
Comment 27•23 years ago
|
||
s/reporter/rangan/ in my previous comments.
Assignee | ||
Comment 28•23 years ago
|
||
it seems to me that the Accept-Charset header which is failing is: Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66 and the one that succeeds is: Accept-Charset: UTF-8, * there is nothing incorrect with the first charset line; however, i suspect that the server may be having trouble parsing it. perhaps the server doesn't like the fact that the "utf-8" is lowercase, or perhaps the server doesn't know how to handle "q" values properly. at any rate, this looks a lot like a broken server to me.
Assignee | ||
Comment 30•23 years ago
|
||
interestingly enough, IE6 doesn't even send an Accept-Charset header. this was added to mozilla along with the "q" values so as to support content negotiation by letting the server know what charset the user would prefer.
Comment 31•23 years ago
|
||
On NT4, I can get the website responding to both 'ISO-8859-1, utf-8;q=0.66, *;q=0.66' and UTF8, *' charsets - verified this again with . It returns the 500 OK error when the "accept charset" field was blank. I found this field to be blank initially, when a build is installed and a fresh profile is created. The "default character coding" field in preferences->navigator->language shows blank; and the browser sends a blank "accept-charset" field [I didn't use a sniffer ... just printed out the http header from inside the code]. Once I changed the "default character coding" to UFT8 , or Western [ISO-8859....], "accept-charset" got the proper value, and things work. I observed this on yesterday evenings codebase, too. I believe if no Accept-Charset is present in the header [as in MSIE or Netscape 4.7] the server might use its default. But if its value is null, the server possibly got confused. Actually, in this case the error was probably thrown by a jsp - the main.jsp is the one that fails to load.
Assignee | ||
Comment 32•23 years ago
|
||
in a debug build, i actually got the page to load correctly once out of two tries. my logs show that in each case an Accept-Charset header with a valid value was sent. rangan: i'm not sure why i'm not seeing the same thing as you.
Assignee | ||
Comment 33•23 years ago
|
||
Assignee | ||
Comment 34•23 years ago
|
||
Assignee | ||
Updated•23 years ago
|
Attachment #49239 -
Attachment is patch: false
Assignee | ||
Comment 35•23 years ago
|
||
each of these were generated by running a debug build of mozilla from the command line as such: ./mozilla -P test https://easyweb.tdcanadatrust.com/ i suspect that there must be some sort of race condition here... i'll try to generate new logs which include the socket log.
Assignee | ||
Comment 36•23 years ago
|
||
the failed http log, shows that the socket transport actually errored out with NS_BINDING_FAILED for both main.jsp and blank.jsp. this could only be caused by PR_Poll setting PR_POLL_EXCEPT or PR_POLL_ERR on the socket.
Assignee | ||
Comment 37•23 years ago
|
||
Assignee | ||
Comment 38•23 years ago
|
||
this is either a server bug or a PSM bug... polling for PR_POLL_READ is resulting in PR_POLL_ERR which prevents main.jsp from loading. this only happens some times, and seems to happen more frequently when using an optimized build. i'm not sure how this correlates with the business of switching default charsets around... it could simply be coincidental that switching to UTF-8 seemed to help. at any rate, there is definitely something weird going on here.
Assignee | ||
Comment 39•23 years ago
|
||
javi, ssaux: looks like a problem detecting a TLS intolerant server. i suspect PSM is setting PR_POLL_ERR when it really should force a premature EOF.
Assignee | ||
Comment 40•23 years ago
|
||
the page loads sometimes b/c PR_POLL_ERR sometimes happens on blank.jsp and other times it happens to main.jsp. both pages are loaded at about the same time, but depending on which one responds first, the results vary. without blank.jsp, the page appears to load correctly, but without main.jsp... there's no hope. -> PSM
Assignee: darin → ssaux
Status: ASSIGNED → NEW
Component: Networking: HTTP → Client Library
Product: Browser → PSM
QA Contact: tever → bsharma
Target Milestone: mozilla0.9.5 → ---
Version: other → unspecified
Comment 41•23 years ago
|
||
Per discussion with Darin today afternoon, this is what I understand is the current situation on this bug. Darin, Pl correct me if I'm wrong. It appears we have two bugs here: 1. The blank "accept-charset" header - which always happens on a FRESH profile, until we go and set the charset in preferences->navigator->language tab. This would be a dup of bug# 97705. As per my observation, with this blank charset, we are never able to load the page. We should mark this bug to be dependent on 97705, as well. 2. The PR_POLL_ERR related trouble, as Darin has pointed out. cc-ing ddrinan on this
Comment 42•23 years ago
|
||
Back to rangan. nsbranch+ If we can get a fix on this, I'd like to see it on the branch. Note that it's true that easyweb.canadatrust.com is TLS intolerant. TLS intolerant flavor B.
Comment 43•23 years ago
|
||
Note that turning on TLS or turning it off still produces an empty page. This may be due to the the fact that the site exercises the two bugs mentioned by Rangan.
Comment 44•23 years ago
|
||
Surprisingly, once I set the languages->charset [to ISO-8, or ISO-8859-1], I never see the problem anymore - the page loads successfully 100% time, whether TLS is enabled or disabled. But before the charset is set [its blank on installation, bug# 97705 ] the page always fails to load - again, irrespective of TSL enabled/disabled. Observations were on NT4, build 2001091703. Reporter - do you see the bug once you set pref->Navigator->Languages->Character Coding? Also, I believe its important we fix the dependency [ bug# 97705 ] because looks like it makes the page fail 100% time.
Depends on: 97705
Comment 45•23 years ago
|
||
Surprisingly, once I set the languages->charset [to ISO-8, or ISO-8859-1], I never see the problem anymore - the page loads successfully 100% time, whether TLS is enabled or disabled. But before the charset is set [its blank on installation, bug# 97705 ] the page always fails to load - again, irrespective of TSL enabled/disabled. Observations were on NT4, build 2001091703. Reporter - do you see the bug once you set pref->Navigator->Languages->Character Coding? Also, I believe its important we fix the dependency [ bug# 97705 ] because looks like it makes the page fail 100% time.
No longer depends on: 97705
Comment 46•23 years ago
|
||
Just noticed 97705 has been marked as a dup of bug# 97606 ... so marking this depends on 97606.
No longer depends on: 97606
Assignee | ||
Comment 47•23 years ago
|
||
rangan: try this on linux... you will see the problem i reported. this is not entirely due to bug 97606.
Comment 48•23 years ago
|
||
we tried this URL on a linux machine with build ID 2001091705.0.9.4 as well as all the links listed on bug 100201 (other reports of blank pages) to no avail. Note that the reporter of bug 100201 solved his problem by migrating a profile from 4.7X to mozilla.
Assignee | ||
Comment 49•23 years ago
|
||
ssaux: what do you mean by "to no avail" ??
Comment 50•23 years ago
|
||
darin: could not get the blank page to appear. Machine configurations may have an effect. I run my linux build over X displaying on a Solaris machine acting as my x terminal. I don't doubt that there is some issue with PSM code, and I would very much like to get a handle on it. We're keeping this bug open in hope that we'll fix the real problem.
Comment 51•23 years ago
|
||
precision: I did get some content on all the urls we tried.
Assignee | ||
Comment 52•23 years ago
|
||
ssaux: thanks for clarifying... and please note, the problem is not 100% reproducible... it only appears to load correctly when blank.js receives the PR_POLL_ERR instead of main.js ... since blank.js is "blank" failing to load it does not cause any perceived problems.
Comment 53•23 years ago
|
||
If you get a fix we want it, otherwise marking nsenterprise- to get it off the stop ship radar
Keywords: nsenterprise+ → nsenterprise-
Comment 54•23 years ago
|
||
*** Bug 100446 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 55•23 years ago
|
||
one possible solution would be to trigger a restart of the http transaction on the socket generating the PR_POLL_ERR. there is already a limit on the number of times a transaction can be restarted, so this would probably be a safe change. but, the required code is non trivial... it would be nice to understand why were seeing a PR_POLL_ERR however. i really suspect that something is wrong inside PSM/NSS.
Assignee | ||
Comment 56•23 years ago
|
||
-> browser
Assignee: rangansen → neeti
Component: Client Library → Networking: HTTP
Product: PSM → Browser
QA Contact: bsharma → tever
Target Milestone: 2.1 → mozilla0.9.5
Version: unspecified → other
Assignee | ||
Comment 58•23 years ago
|
||
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 59•23 years ago
|
||
rangan and i tested this patch... it appears to solve the problem 100%. we determined that PR_POLL_ERR is resulting from the server resetting the socket connection. the server sends a Keep-Alive header with a timeout=5, so our guess is that the server is being very strict about enforcing this timeout. anyways, this patch may help with a bunch of the other "blank page" bugs, and i think we should strongly consider this patch for nsbranch/nsenterprise.
Comment 60•23 years ago
|
||
Comment on attachment 50022 [details] [diff] [review] v1.0 patch; makes necko restart http transactions that fail on PR_POLL_ERR r=bbaetz
Attachment #50022 -
Flags: review+
Comment 61•23 years ago
|
||
Comment on attachment 50022 [details] [diff] [review] v1.0 patch; makes necko restart http transactions that fail on PR_POLL_ERR sr=me. Please add a comment to the nsISocketTransportService.idl to describe what NS_ERROR_NET_RESET means.
Assignee | ||
Comment 62•23 years ago
|
||
Assignee | ||
Updated•23 years ago
|
Attachment #50022 -
Attachment is obsolete: true
Assignee | ||
Comment 63•23 years ago
|
||
Comment on attachment 50116 [details] [diff] [review] v1.1 revised per comments from dougt has r=bbaetz, sr=dougt
Attachment #50116 -
Flags: superreview+
Attachment #50116 -
Flags: review+
Assignee | ||
Updated•23 years ago
|
Whiteboard: ready-to-land
Assignee | ||
Comment 65•23 years ago
|
||
targeting 0.9.4 branch ... awaiting PDT+
Target Milestone: mozilla0.9.5 → mozilla0.9.4
Reporter | ||
Comment 66•23 years ago
|
||
Tried latest version (2001092003, Win2K Pro SP1) and now attempting to access the easyweb login (easyweb.tdcanadatrust.com) keeps the browser busy with "Sending request to easyweb.tdcanadatrust.com" in the status bar, but no page access. My default character coding is still at UTF-8, which had allowed me access to the EasyWeb logon previously. To see if this had anything to do with trying to access a secure page on the site, I tried http://www.tdcanadatrust.com/tdvisa/security/green_security.html, pressed the "Proceed with application" button, with a similar result to above -- "Connecting to secure.tdcanadatrust.com" in status bar but no connect. Non-https pages work fine. Can access pages fine from Netscape 4.75 and IE 5.5
Comment 67•23 years ago
|
||
Build 2001092003 probably would still not have the patch in it. This seems to work fine for me on NT4 with todays trunk build [2001092103]. Looks like works fine for Stephane, too, on Win2K, with the branch build.
Assignee | ||
Comment 68•23 years ago
|
||
Christopher Archer: you need to try a newer build.
Assignee | ||
Comment 70•23 years ago
|
||
fixed-on-branch
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Whiteboard: fixed-on-trunk,PDT+ → fixed-on-trunk,PDT+,fixed-on-branch
Reporter | ||
Comment 71•23 years ago
|
||
Note: I have tried the latest nightly build (2001092103): removed existing Mozilla install, cleared caches, etc. With latest version (2001092103, Win2K Pro SP1), attempting to access the easyweb login (easyweb.tdcanadatrust.com) keeps the browser busy with "Sending request to easyweb.tdcanadatrust.com" in the status bar, but no page access. My default character coding is still at UTF-8, which had allowed me access to the EasyWeb logon previously. Repeating a previous second test I had performed before to see if this had anything to do with trying to access a secure page on the site, I tried http://www.tdcanadatrust.com/tdvisa/security/green_security.html, pressed the "Proceed with application" button. Status bar flashes "Connecting to secure.tdcanadatrust.com", then "Done", but the page does not change (URL in address bar also unchanged. Non-https pages work fine. Can access "problem" pages fine from Netscape 4.75 and IE 5.5
Assignee | ||
Comment 72•23 years ago
|
||
with a debug win2k build, pulled on 9/26, i had no problems accessing the page https://easyweb.tdcanadatrust.com/
Assignee | ||
Comment 73•23 years ago
|
||
are you talking about a problem that occurs after you press the login button?
Reporter | ||
Comment 74•23 years ago
|
||
Yes, the desired page does NOT display after pressing the "Login now" button: Mozilla indicates it is attempting to connect, but never does. Able to reproduce consistently, clearing caches in between attempts.
Assignee | ||
Comment 75•23 years ago
|
||
ok, so without a username/password, it's going to be difficult for me to debug this... chris: do you have a debug build that you can test?
Comment 76•23 years ago
|
||
Darin, do you want to open a new bug for the login problem or do you think it is related to this bug? We would have to ask chris to do this since I do not have access to the site.
Assignee | ||
Comment 77•23 years ago
|
||
chris: can you please file a new bug for this _other_ problem. i suspect that you originally meant this bug to convey the problem you are now describing, but it seems that it morphed into something else.. so if you could please file a new bug that would be very helpful. thanks!
Comment 78•23 years ago
|
||
verified on branch, original url is working for me Win NT4 2001-09-28-05-0.9.4 Linux rh6 2001-09-28-04-0.9.4 Mac osX 2001-09-28-04-0.9.4
Keywords: vtrunk
Whiteboard: fixed-on-trunk,PDT+,fixed-on-branch → fixed-on-trunk,PDT+
Comment 79•23 years ago
|
||
*** Bug 106865 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•