Closed Bug 84336 Opened 23 years ago Closed 23 years ago

ecommerce sites deliver blank pages if cipher is not available

Categories

(Core Graveyard :: Security: UI, defect, P1)

Product:
Core Graveyard
Component:
Security: UI
Version:
1.0 Branch
Platform:
x86
Windows 2000
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
psm2.1

People

(Reporter: lord, Assigned: inactive-mailbox)

References

Details

Attachments

(1 file)

Suggested fix, but asking for further analysis
726 bytes, patch
Details | Diff | Splinter Review 
In recent builds, some HTTPS sites show empty pages.  When you View Source, the
pages look like this:

<html><body></body></html>

Here are some sites that exhibit this behavior:
https://www.netplaza.com/
https://www.cofcu.org/onlineserv/HB/Signon.cgi
https://www.communitycu.org/sign-on.html
https://www.affinityfcu.org/welcome.html
-> 2.0, P2

We need to understand why this is happening before RTM.  Can someone investigate?
Priority: -- → P2
Target Milestone: --- → 2.0
Version: 1.01 → 2.0
*** Bug 60933 has been marked as a duplicate of this bug. ***
I tried these sites with today's commercial Linux build and they all worked fine.
I just tried on the latest commercial windows branch build and all of these 
sites load successfully. Resolving WORKSFORME.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
David: including win2000?
Using my latest trunk build, these sites work on win2k. I'll try the branch 
build next.
Tested the latest branch builds on win2k and *all* of these sites load 
successfully.
Reopening. You will get a blank page when visiting an SSL2 only site with 
only SSL3 enabled, and vice versa.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Summary: ecommerce sites deliver blank pages → ecommerce sites deliver blank pages if cipher is not available
Confirmed.  These sites must be SSL2 sites.  When I turn SSL2 on, I can access
them.  Good work.

The SSL library has specific error codes that it returns in these cases
of no protocol or cipher suite match.  Evidently, PSM isn't taking
notice of those error codes.
Mass reassigning target to 2.1
Target Milestone: 2.0 → 2.1
Keywords: nsenterprise
P1
Priority: P2 → P1
These pages were delivering blank pages because lord had SSL v2 disabled.  Now
you get an alert saying the SSL v2 is disabled nad that's why you can't connect.

Seems like this bug should be marked as fixed or a dup of 33772
You still get blank pages if cipher is not available. You just get a warning 
first.
goal is to show warning and stay on the current page

*** Bug 90850 has been marked as a duplicate of this bug. ***
Adding darin and bbaetz to cc list, FYI.

I debugged this.

What happens: Although the connection was aborted, the method
nsHttpChannel::OnStartRequest will still be called. This method recognizes that
no mResponseHead is available and goes to mListener->OnStartRequest, which ends
up at nsDocumentOpenInfo::OnStartRequest. Arriving there,
httpChannel->GetResponseStatus gets called. However, this function fails. It
returns an error code (as now response head is available). The problem: The
error code from GetResponseStatus is not checked.

I added the check to the return code, and if a failure is detected, return
immediately from the function. This prevents an empty document to be created and
shown. The behaviour is then as expected, the previous document will remain in
the document area of the browser.Darin, Bbaetz: While this fixes the problem, I
want to point you to an additional location that you might want to check. The
method nsHttpChannel::OnStartRequest never uses it's parameter request, besides
for the debug log (and that's the reason why you might have never seen a "not
used" warning from the compiler).
Is it possible that the call to mListener->OnStartRequest shouldn't use "this"
as the first parameter, but the "request" argument? Just an idea.

I suggest to change the Product of this bug to "Browser" and component to
"Networking: HTTP".

cc'ing sspitzer

Seth, can you please review this patch?

r=bbaetz. darin, sr?
uriloader patches should go through mscott for review, he's the module owner.
using "this" as the first parameter to mListener->OnStartRequest is correct.
clients of an nsIHttpChannel, expect nsIStreamListener methods to arrive with
the request being the nsIHttpChannel.

your patch sounds correct to me.  however, i really think that mscott should
take a look at this patch.
adding patch keyword.
Keywords: patch
-> Kai
Assignee: ddrinan → kai.engert
Status: REOPENED → NEW
-> Kai
Status: NEW → ASSIGNED
sr=mscott
Mass assigning QA to ckritzer.
QA Contact: junruh → ckritzer
Checked in patch for Kai.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
keywords->verifyme
Keywords: patch → verifyme
Reopening. The 4 sites in the original bug description still give a blank page 
if SSL2 is off.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
There is one szenario that makes this bug confusing to test.
However, I still think the bug is fixed.

Let me explain how you can verify this.
Preparation: 
- Configure your browser to start with a blank page.
- turn off SSL2

Szenario 1)
===========
Stop the browser.
Start the browser. It displays an empty page.
Now go to https://www.netplaza.com/
When I do this, I get a warning.
After I clicked OK in the warning, the browser still displays an empty page.
This is how I expect it to be.
As there previously was nothing to show, the browser should still display an
empty page.

Szenario 2)
===========
Stop the browser.
Start the browser. It displays an empty page.
Go to http://www.mozilla.org
Wait for the page to load.
Now go to https://www.netplaza.com/
When I do this, I get a warning.
After I clicked OK in the warning, the browser still displays the Mozilla homepage.


junruh, can you please try these steps? Does it behave like I described or do
you see something different?

Marking fixed with the 8/3 WinNT trunk build.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Verified.
Status: RESOLVED → VERIFIED
Product: PSM → Core
Version: psm2.0 → 1.0 Branch
Keywords: verifyme
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: