Closed Bug 98203 Opened 24 years ago Closed 10 months ago

Timeout during SSL handshake causes about: blank to be displayed

Categories

(Core :: Networking, defect, P5)

Product:
Core
Component:
Networking
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: cfu, Unassigned)

References

(
URL
)

Details

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

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.
Assignee: ssaux → rangansen
Priority: -- → P1
Target Milestone: --- → 2.1
setting to P1, t->2.1
maybe the same problem as 97997
Keywords: nsenterprise
Marking nsentreprise+
Keywords: nsenterprise → nsenterprise+
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: nsbranch+
Group: netscapeconfidential?
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.
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
Whiteboard: <html><body></body></html> bug
gagan
Assignee: neeti → gagan
Whiteboard: <html><body></body></html> bug → PDT <html><body></body></html> bug
-->darin
Assignee: gagan → darin
This does not look like a stop ship from the enterprise perspective. Marking nsenterprise-.
Keywords: nsenterprise+ → nsenterprise-
Darin - What's the status on this one?
-> mozilla 0.9.5 ... i have yet to investigate this bug.
Target Milestone: M1 → mozilla0.9.5
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
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.
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.
christina: can you verify the problem with a 9/21 build?
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.
ssaux: thanks for the feedback... i'll try to investigate this problem on monday.
Status: NEW → ASSIGNED
status pls ... we'd like this one.
Whiteboard: PDT <html><body></body></html> bug → [PDT], <html><body></body></html> bug
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?
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.
Whiteboard: [PDT], <html><body></body></html> bug → [PDT], <html><body></body></html> bug, [ETA ?]
I've seen this one on occassion on www.techcu.com
URL: www.techcu.com
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?
FWIW, IE5.5 doesn't seem to have this problem
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).
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?
what are the chances this will make the 0.9.4 branch?
probably not, since we don't really have any idea how to solve the problem yet.
*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?
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.
PDT-, since this will not make the branch.
Whiteboard: [PDT], <html><body></body></html> bug, [ETA ?] → [PDT-], <html><body></body></html> bug, [ETA ?]
-> mozilla 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
The <html><body></body></html> problem is also bug 102737.
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
Blocks: 107066
Keywords: nsbranch+
cc'ing evangelist to see if they have heard of this stuff happening in the wild for this or other related bugs mentioned.
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.
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
Keywords: nsbeta1
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
No longer blocks: 107066
updated summary...
Summary: Page does not display proper info when http connection snaps midway → Timeout during SSL handshake causes about: blank to be displayed
-> 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]
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P2 → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Severity: major → S4
Priority: P3 → P5
Status: NEW → RESOLVED
Closed: 10 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.