Closed Bug 97997 Opened 23 years ago Closed 23 years ago

easyweb.tdcanadatrust.com does not display

Categories

(Core :: Networking: HTTP, defect, P1)

defect

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)

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)
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?
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
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
P1, t->2.1
rangansen
Assignee: ssaux → rangansen
Priority: -- → P1
Target Milestone: --- → 2.1
Keywords: nsenterprise
Using Linux Build ID : 2001090408, I can reproduce the problem. Therefore I'm
not sure this is a PSM bug.
Marking nsentreprise+
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...
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?

as boris mentioned, this doesn't seem to be a problem under linux... testing
winnt (i don't have a win2k box handy).
i'm able to reproduce this problem in a 8/31 winnt build.  investigating...
ugh.. i'm having trouble getting a PSM win32 build.. will get back to this later.
rangan: it would be helpful if you could generate a socket transport log and
attach it to this bug.
Attached file Socket Transport Log
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).
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...
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.
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
adding Stephane to cc list
changing summary
Summary: Page does not display → easyweb.tdcanadatrust.com does not display
Nominating nsbranch.
Keywords: nsbranch
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.
Shoot me, please! Switching skins did not work, but setting the default 
character set did (build 2001090904, Win2K SP1)
-> me... there's a dup someplace of the missing Accept-Charset header bug.
Assignee: neeti → darin
Darin/Gagan - IS this gonna be fixed this round, or should we nsbranch- this bad
boy?
-> 0.9.5 until i locate the dup
Status: NEW → ASSIGNED
Target Milestone: M1 → mozilla0.9.5
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?
s/reporter/rangan/ in my previous comments.
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.
Platform:OS -> All:All
OS: Windows 2000 → All
Hardware: PC → All
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.
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.
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.
Attachment #49239 - Attachment is patch: false
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.
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.
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.
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.
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
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
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.
Assignee: ssaux → rangansen
Keywords: nsbranchnsbranch+
Target Milestone: --- → 2.1
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.
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
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
Depends on: 97606
Just noticed 97705 has been marked as a dup of bug# 97606 ... so marking this
depends on 97606.
No longer depends on: 97606
rangan: try this on linux... you will see the problem i reported.  this is not
entirely due to bug 97606.
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.
ssaux: what do you mean by "to no avail" ??
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.
precision: I did get some content on all the urls we tried.
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.
If you get a fix we want it, otherwise marking nsenterprise- to get it off the
stop ship radar
*** Bug 100446 has been marked as a duplicate of this bug. ***
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.
-> 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
-> me (i have a patch)
Assignee: neeti → darin
Status: NEW → ASSIGNED
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 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 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.
Attachment #50022 - Attachment is obsolete: true
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+
Whiteboard: ready-to-land
fixed-on-trunk
Whiteboard: ready-to-land → fixed-on-trunk
targeting 0.9.4 branch ... awaiting PDT+
Target Milestone: mozilla0.9.5 → mozilla0.9.4
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
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.
Christopher Archer: you need to try a newer build.
check it in - PDT+
Whiteboard: fixed-on-trunk → fixed-on-trunk,PDT+
fixed-on-branch
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Whiteboard: fixed-on-trunk,PDT+ → fixed-on-trunk,PDT+,fixed-on-branch
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
with a debug win2k build, pulled on 9/26, i had no problems accessing the page
https://easyweb.tdcanadatrust.com/
are you talking about a problem that occurs after you press the login button?
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.
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?
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.
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!
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+
*** 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.

Attachment

General

Creator:
Created:
Updated:
Size: