Timeout during SSL handshake causes about: blank to be displayed

NEW
Unassigned

Status

()

P3
major
18 years ago
a year ago

People

(Reporter: cfu, Unassigned)

Tracking

Trunk
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT-], [necko-backlog], URL)

(Reporter)

Description

18 years ago
I have a CMS4.2 sp2.  When I point my Netscape6 2001083003 at the agent url, and
signed in as an agent, the first page I see is always
"<html><body></body></html>".  After reload, it's ok.

Updated

18 years ago
Assignee: ssaux → rangansen
Priority: -- → P1
Target Milestone: --- → 2.1

Comment 1

18 years ago
setting to P1, t->2.1

Comment 2

18 years ago
maybe the same problem as 97997

Updated

18 years ago
Keywords: nsenterprise

Comment 3

18 years ago
Marking nsentreprise+
Keywords: nsenterprise → nsenterprise+

Updated

17 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

17 years ago
Keywords: nsbranch+

Updated

17 years ago
Group: netscapeconfidential?

Comment 4

17 years ago
I trust this is some kind of server timeout problem. We get a
PR_CONNECT_RESET_ERROR whenever the problem shows up, implying the server quits
the connection[probably times out].  
Sounds a bit weired, but this is what I observed:
When I Try to visit a ssl enable cms server url [https://cfu:8100, for example]
I am propmted for my certificate. If I select the certificate and put in thec
password etc fast enough, things go ok. But if I wait for more that a minute, or
so, I get . This can be almost always reproduced using Netscape 6, as well as
communicator 4.7.
Looks like this might be a cms server related bug. Also, I could not find any
way to set the timeout in the cms server.
cfu: what are your views on this issue?
Also, including Stephane in the cc list.

Comment 5

17 years ago
Okay, so this is resolved - this was a timeout problem - default timeout on cms
server, I was told, was set to 15 sec by default.

But this still leaves another problem - when connection snaps during the data
exchange, the page should not show "<html><body></body></html>" as it does now -
this would be wrong as this  data was never received. Communicator used to show
a dialog box indicating a network error. We should have something like that, or
may be a error page, showing the error details etc.

This happens in number of other places, but this particular bug would provide a
good ready-made test case. So, I am changing the summary of this bug as
relevant, and assigning this to network module.
Assignee: rangansen → neeti
Component: Client Library → Networking: HTTP
Product: PSM → Browser
QA Contact: bsharma → tever
Summary: no body in page after ssl client auth → Page does not display proper info when http connection snaps midway
Target Milestone: 2.1 → M1
Version: 2.0 → other

Updated

17 years ago
Whiteboard: <html><body></body></html> bug

Comment 6

17 years ago
gagan
Assignee: neeti → gagan

Updated

17 years ago
Whiteboard: <html><body></body></html> bug → PDT <html><body></body></html> bug

Comment 7

17 years ago
-->darin
Assignee: gagan → darin

Comment 8

17 years ago
This does not look like a stop ship from the enterprise perspective.  Marking
nsenterprise-.
Keywords: nsenterprise+ → nsenterprise-

Comment 9

17 years ago
Darin - What's the status on this one?

Comment 10

17 years ago
-> mozilla 0.9.5 ... i have yet to investigate this bug.
Target Milestone: M1 → mozilla0.9.5

Comment 11

17 years ago
Gagan - Can you take a look at this one? It looks pretty serious, and we'd like
this one in ... Pls come to the PDT tomorrow @ noon to discuss the progress on
this bug.
Severity: normal → critical

Comment 12

17 years ago
we need a testcase for this bug... can someone provide a testcase?  it's
possible that my fix for bug 97997 will fix this as well, but without a
testcase, i cannot be certain.
(Reporter)

Comment 13

17 years ago
0. get a new profile
1. go to http://cfu [Enrollment][Directory], enter uid "teest1" and password
"test1" [Submit] (now you got yourself a cert
2. make sure the ca is trusted in your certificate manager.
3. visit https://cfu:8100, you'll be presented with the ssl client auth cert
selection.  Don't do anything, just sit there and wait for over 1 minute.

After that minute+, just select the cert and "ok" (you might be asked to log
into your software token, if you haven't done so before), you'll see it.

Comment 14

17 years ago
christina: can you verify the problem with a 9/21 build?

Comment 15

17 years ago
Darin: I was able to get a <html><body></body></html> page using today's branch
build. If you want me to try other builds, ask me. Christina's running full
functional test on an earlier build.

Notes:
- Configure to have your browser to "Ask everytime" for client auth cert
selection (pref->priv&sec->certificates)

- The user for the directory enrollment is test1/test1. Christina's comment had
a typo.

- Once you have the cert, it's sufficient to go directly to https://cfu:8100.
If you get an Unauthorized access (what should happen if the bug wasn't there)
and reloading the page always gives you that, you can get out of it by doing
task->priv&sec->pwd mng->log out.

- Finally, just in case this isn't specified the unexpected result occurs when
the server reaches it's configured timeout to complete the full handshake
including the client auth.

Comment 16

17 years ago
ssaux: thanks for the feedback... i'll try to investigate this problem on monday.
Status: NEW → ASSIGNED

Comment 17

17 years ago
status pls ... we'd like this one.
Whiteboard: PDT <html><body></body></html> bug → [PDT], <html><body></body></html> bug

Comment 18

17 years ago
Since this says we behave identically to 4.x, and there are no serious
consequences of the error, why is this P1 critical?  I understand the desire to
have a good error message, but is this a situation that millions of people are
going to run into?

Comment 19

17 years ago
it's unclear at this point how many consumers would be effected by this bug, but
i suspect that it is not that many.  however, if this is not a problem with IE,
then it would just be additional encouragement for a user to not use ns/mozilla.

i'll have some more comments later tonight.

Updated

17 years ago
Whiteboard: [PDT], <html><body></body></html> bug → [PDT], <html><body></body></html> bug, [ETA ?]

Comment 20

17 years ago
I've seen this one on occassion on www.techcu.com

Comment 21

17 years ago
ok, i've reproduced this bug... it is very easily reproducible.  however, i
suspect the fix will be very involved.  the problem is that we have already read
some data from the socket, when suddenly a call to PR_Read returns 0xffffe8d8 or
PR_CONNECT_ABORTED_ERROR.  i don't understand why the server chooses to abort
the connection part way through, but i suspect that it means that we should not
be blocking the connection with a UI dialog.  making the dialog non-modal is
probably not easy... ssaux: your thoughts?

Comment 22

17 years ago
FWIW, IE5.5 doesn't seem to have this problem

Comment 23

17 years ago
The test case involving the client auth is not in my opinion dependend on
whether or not the various dialogs (master pwd, cert chooser) are modal or not.

During the SSL handshake with client auth, the server and the client have sent
each other strings of random bytes, and the server has requested that the client
sign a massaged version of this data with a client private key that matches the
CA/purpose listed in the server request. At this point, the client presents the
user with the choices of matching certs/keys.  Once the selection is complete,
the signing operation takes place, and the signed data plus the certificate
chain corresponding to the private key used to sign the data is sent to the server.

The connection snap occurs between the time the server request is received and
the time the signed data/certificate chain is sent.  I don't see a way in which
the modality of the various dialog could affect the outcome.

cc ddrinan.

When you say that it works with I.E., do you mean the client auth test case
(cfu:8100, with a cert select dialog which allows the timeout to be reached)?

Finally, in the case of the cfu:8100 site, the server snaps the connection as a
matter of policy (no data received before before timeout delay).

Comment 24

17 years ago
ssaux: with IE is repeated the exact same test steps outlined above:

1- got a cert
2- went to https://cfu:8100/
3- got a select dialog
4- waited several minutes
5- got the "Unauthorized access" page

(not sure how to duplicate the "Ask Everytime" mozilla preference in IE, or even
if it is essential to this bug)

i understand your point about modal dialogs vs. non-modal dialogs.  no matter
what we have to wait for the user's input, and it seems that once we exceed some
threshold delay, the server times out.  so, then how do we recover from this
timeout?  can we in fact recover from it?  i'm not sure we can since the socket
transport has already read data... would it really make sense to restart the
HTTPS transaction on a new connection?  wouldn't that go through the same cert
select dialog fu?

Comment 25

17 years ago
what are the chances this will make the 0.9.4 branch?

Comment 26

17 years ago
probably not, since we don't really have any idea how to solve the problem yet.

Comment 27

17 years ago
*sigh* ok ... keep working on it, and let us know of any good news. i think it
would be a  good thing to have for the release. thanks ...

p.s. - this is not a regression, right? did 0.9.2 and 0.9.2 ship with this?

Comment 28

17 years ago
i don't think this is a regression.  in fact, the problem exists with netscape
4x as well.  only IE seems to handle this problem correctly.

Comment 29

17 years ago
PDT-, since this will not make the branch.
Whiteboard: [PDT], <html><body></body></html> bug, [ETA ?] → [PDT-], <html><body></body></html> bug, [ETA ?]

Comment 30

17 years ago
-> mozilla 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6

Comment 31

17 years ago
The <html><body></body></html> problem is also bug 102737.

Comment 32

17 years ago
I'm hoping to find time to help develop a solution sometime in the mozilla 0.9.8
timeframe.
Target Milestone: mozilla0.9.6 → mozilla0.9.8

Updated

17 years ago
Blocks: 107066

Updated

17 years ago
Keywords: nsbranch+

Comment 33

17 years ago
cc'ing evangelist to see if they have heard of this stuff happening in the wild
for this or other related bugs mentioned.

Comment 34

17 years ago
we use extensively Cocoon as a content manager.
and we have this error very very often. somthing like once each minute or so.

no reproductible thing, but very annoying.

as said in the previous comments, IE does handle the problem flawless.

Comment 35

17 years ago
i'm not sure anything can be done about this in the mozilla1.0 timeframe.  seems
like a major architectural change to avoid connection timeouts when modal
dialogs  are left unattended.

-> future
Severity: critical → major
Priority: P1 → P2
Target Milestone: mozilla0.9.8 → Future

Updated

17 years ago
Keywords: nsbeta1

Comment 36

17 years ago
gonna go ahead and nsbeta1- this one per darin's comments.
Keywords: nsbeta1 → nsbeta1-
Whiteboard: [PDT-], <html><body></body></html> bug, [ETA ?] → [PDT-], <html><body></body></html> bug

Updated

17 years ago
No longer blocks: 107066

Comment 37

16 years ago
updated summary...
Summary: Page does not display proper info when http connection snaps midway → Timeout during SSL handshake causes about: blank to be displayed

Comment 38

13 years ago
-> default owner
Assignee: darin → nobody
Status: ASSIGNED → NEW
Component: Networking: HTTP → Networking
QA Contact: tever → networking
Target Milestone: Future → ---
Whiteboard: [PDT-], <html><body></body></html> bug → [PDT-], [necko-backlog]
You need to log in before you can comment on or make changes to this bug.