Closed
Bug 268483
Opened 20 years ago
Closed 20 years ago
Lock icon appears even though http connection failed.
Categories
(Core :: Networking: HTTP, defect)
Core
Networking: HTTP
Tracking
()
VERIFIED
FIXED
mozilla1.8beta1
People
(Reporter: dougt, Assigned: darin.moz)
References
()
Details
(Keywords: fixed-aviary1.0.1, fixed1.7.6, Whiteboard: [sg:fix])
Attachments
(3 files)
2.26 KB,
patch
|
Biesinger
:
review+
|
Details | Diff | Splinter Review |
2.34 KB,
patch
|
Biesinger
:
review+
bzbarsky
:
superreview+
dveditz
:
approval-aviary1.0.1+
dveditz
:
approval1.7.6+
|
Details | Diff | Splinter Review |
2.35 KB,
patch
|
Biesinger
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
steps to reproduce: 1. Go to http://mozilla.org 2. Go to a https server that doesn't speak https. For example, a https imap server. expected result: an error dialog and the content of the page shouldn't change. most importantly, the security of the page should remain the same -- lock icon unlocked. actual result: i see an error dialog, but then the lock icon is locked and the details in the page security dialog suggest that www.mozilla.org has been verified. marking security sensitive per conversation with darin
Assignee | ||
Updated•20 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.8beta
Comment 1•20 years ago
|
||
*** Bug 270676 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 2•20 years ago
|
||
I found a public secure IMAP server that can be used to demonstrate this bug: https://calmail.berkeley.edu:993/ Load that link, and then press the STOP button. You should see the address bar change to the locked state for the calmail server even though the page content hasn't changed. The choice of the STOP button is not special... any error condition would likely yield the same result.
Assignee | ||
Comment 3•20 years ago
|
||
I believe this bug is a result of the patch for bug 148981. I think it may be wrong to synthesize a STATE_TRANSFERRING event when the status of the request is a failure code and when it has not already transferred some data (the only case where we would be synthesizing STATE_TRANSFERRING). That patch was added in 2002 by rpotts, and I later added a further condition that we skip that block of code when the status code is NS_ERROR_BINDING_RETARGETED to fix security bug 257308. Now, I think we should just remove that block of code. Patch coming up...
Assignee | ||
Comment 4•20 years ago
|
||
Assignee | ||
Comment 5•20 years ago
|
||
BTW, the reason why "httpChannel->GetResponseStatus(...)" was succeeding was because we treated the text from the IMAP server as a HTTP/0.9 response (i.e., a HTTP response with no status line or response headers).
Assignee | ||
Updated•20 years ago
|
Attachment #169740 -
Flags: review?(cbiesinger)
Updated•20 years ago
|
Attachment #169740 -
Flags: review?(cbiesinger) → review+
Assignee | ||
Comment 6•20 years ago
|
||
biesi raised an interesting point over irc: It seems that this patch works because the HTTP channel's direct listener is not the URI loader but rather an unknown content decoder. It suppresses the ODA because it is trying to figure out what sort of content the stream contains. Perhaps it would make more sense to check if the request has been targeted or not in place of the block of code I removed. Only a targeted request (one with the nsIChannel::LOAD_TARGETED load flag set) should trigger STATE_TRANSFERRING (I think). I might give that a try instead...
Assignee | ||
Comment 7•20 years ago
|
||
alternate patch.
Comment 8•20 years ago
|
||
Comment on attachment 169752 [details] [diff] [review] v2 patch yeah... I think this is a better approach. I still wonder why the data just disappears, though... anyway, r=biesi.
Attachment #169752 -
Flags: review+
Assignee | ||
Comment 9•20 years ago
|
||
it doesn't dissappear... instead it is stuck inside the unknown decoder's internal buffer. the decoder is waiting for the next ODA, but instead it gets an OnStopRequest w/ status=NS_BINDING_ABORTED. thus, the data is never pushed to the final stream listener.
Assignee | ||
Updated•20 years ago
|
Attachment #169752 -
Flags: superreview?(bzbarsky)
![]() |
||
Comment 10•20 years ago
|
||
Comment on attachment 169752 [details] [diff] [review] v2 patch sr=bzbarsky
Attachment #169752 -
Flags: superreview?(bzbarsky) → superreview+
Assignee | ||
Comment 11•20 years ago
|
||
fixed-on-trunk dougt, is there any way you can verify the fix?
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Whiteboard: [sg:fix]
Comment 12•20 years ago
|
||
Shouldn't this be ported back to the branches?
Updated•20 years ago
|
Flags: blocking-aviary1.1?
Updated•20 years ago
|
Flags: blocking-aviary1.0.1?
Updated•20 years ago
|
Flags: blocking1.7.6?
Flags: blocking1.7.6+
Flags: blocking-aviary1.0.1?
Flags: blocking-aviary1.0.1+
Comment 13•20 years ago
|
||
Comment on attachment 169752 [details] [diff] [review] v2 patch a=dveditz
Attachment #169752 -
Flags: approval1.7.6+
Attachment #169752 -
Flags: approval-aviary1.0.1+
Assignee | ||
Updated•20 years ago
|
Keywords: fixed-aviary1.0.1,
fixed1.7.6
Assignee | ||
Comment 14•20 years ago
|
||
*** Bug 280461 has been marked as a duplicate of this bug. ***
Comment 15•20 years ago
|
||
Verified Fixed. Test case with https://calmail.berkeley.edu:993/ no longer displays yellow background and lock icon when the page load is stopped. M18b1/Trunk: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050217 Aviary 1.0.1 Branch: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20050218 Firefox/1.0 M176 Branch: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050217 Based on my testing, it looks like this has been fixed everywhere.
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Group: security
Updated•20 years ago
|
Flags: blocking-aviary1.1?
Comment 16•20 years ago
|
||
Updated•20 years ago
|
Attachment #187613 -
Flags: superreview?(bzbarsky)
Attachment #187613 -
Flags: review?(cbiesinger)
Updated•20 years ago
|
OS: Windows XP → All
Updated•20 years ago
|
Attachment #187613 -
Flags: review?(cbiesinger) → review+
![]() |
||
Updated•19 years ago
|
Attachment #187613 -
Flags: superreview?(bzbarsky) → superreview+
You need to log in
before you can comment on or make changes to this bug.
Description
•