wrong behavior with "http/1.1 204 no content"

VERIFIED FIXED in mozilla1.8beta1

Status

()

Core
Security
VERIFIED FIXED
13 years ago
10 years ago

People

(Reporter: Mathieu Deaudelin-Lemay (previous account), Assigned: Darin Fisher)

Tracking

(Blocks: 1 bug, {fixed-aviary1.0.1, fixed1.7.6})

Trunk
mozilla1.8beta1
fixed-aviary1.0.1, fixed1.7.6
Points:
---
Bug Flags:
blocking1.7.6 +
blocking-aviary1.0.1 +
blocking1.8b +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:fix], URL)

Attachments

(3 attachments, 1 obsolete attachment)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217

If a website returns a "Http/1.1 204 No Content" header to the browser, Mozilla
will not replace the page you were visiting. However, the browser will display
the new address in the address bar.

So, if you are visiting http://whateversite.com and then you click on a link to
https://nexus.passport.com/, Mozilla will display "https://nexus.passport.com/"
in your address bar. Mozilla will also display a lock icon in the status bar. If
you double-click on the lock, Mozilla will display a dialog box saying :

"The website whateversite.com supports authentication for the page you are
visiting..."

If you click on the View button, Mozilla shows nexus.passport.com's certificate.

Firefox goes even further by highlighting the address bar and adding a lock icon
near the address. A lock is also added to the status bar beside the string 
"whateversite.com".

I will post a screenshot later.

I could confirm this bug in Firefox 1.0 and Mozilla 1.7.5.

Reproducible: Always

Steps to Reproduce:
1. Go to www.mozilla.org for instance.
2. In your address bar, type the URI of any page who returns a HTTP 204 header.
   (I recommend you to use a HTTPS page)
3. Look at your address bar, check the status bar for a lock icon.

Actual Results:  
Mozilla kept the "204" URI in the address bar, but added lock icons to the
interface.

Expected Results:  
Mozilla should update the URL to match the one of the web page visited by the
user. It should not add locks saying that the content is secure.
Created attachment 170060 [details]
Screenshot of this bug in Firefox 1.0
Correction : Mozilla will *not* change the contents of the address bar when you
click on a link who returns "http 204 no content". This was an error during my
tests.

However, Mozilla will still add lock icons to the interface (see the screenshot).
Created attachment 170061 [details]
Test page for this bug

This replaces the screenshot i had posted. sorry for all this spam.
Attachment #170060 - Attachment is obsolete: true
fixed with bug 268483 maybe?
hm, obviously not - still seeing this in a trunk build (linux)
OS: Windows XP → All
-> Darin
Assignee: dveditz → darin
Hmm.. I don't get it.  204 responses are dropped before ever entering content
dispatch, so they never have LOAD_TARGETED set.

Confirming bug, but I'm really not sure where the security UI is getting its
notifications from.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8b?
Hardware: PC → All
(Assignee)

Comment 8

12 years ago
This sounds like it could be leveraged to spoof the user in a similar fashion to
bug 278003.  Marking Security-Sensitive.

For example:

Load http://www.not-paypal.com/ which is a fake paypal.com, and then load some
https://www.paypal.com/link/that/happens/to/return/204 (assuming paypal.com has
such a link somewhere on their site).
Group: security
Status: NEW → ASSIGNED
(Assignee)

Comment 9

12 years ago
forget i mentioned paypal... the fact that this can be used to spoof
passport.com sounds plenty serious to me.

Updated

12 years ago
Flags: blocking1.8b? → blocking1.8b+
This sounds an awful lot like the timing issues in several of the other lock
icon bugs. Will this fall out of those fixes?
Blocks: 130949
Flags: blocking1.7.6?
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.0.1?
Whiteboard: [sg:fix]
We need to get this one too on the branches.
Flags: blocking1.7.6?
Flags: blocking1.7.6+
Flags: blocking-aviary1.0.1?
Flags: blocking-aviary1.0.1+
(Assignee)

Comment 12

12 years ago
Created attachment 173818 [details] [diff] [review]
v1 patch

This bug was caused by the fact that DocLoader was treating 204 and 205 as
successful page loads, and as a result it synthesized a STATE_TRANSFERRING
event for the request, which triggered SecureBrowserUI to update the lock icon
state.

This patch takes the simple route of returning an error code to necko to
indicate that URILoader is not interested in 204 or 205 responses.

We could also make DocLoader check for 204 and 205, but this seemed simpler. 
The only "downside" to this patch is that WebProgressListeners will now see
that we 204 and 205 responses are canceled.  But, I can live with that :)
Attachment #173818 - Flags: superreview?(bzbarsky)
Attachment #173818 - Flags: review?(cbiesinger)
(Assignee)

Updated

12 years ago
Target Milestone: --- → mozilla1.8beta1
Comment on attachment 173818 [details] [diff] [review]
v1 patch

sr=bzbarsky, but please file a followup bug as we discussed on the docloader,
what things we should synthesize STATE_TRANSFERRING for, etc.
Attachment #173818 - Flags: superreview?(bzbarsky) → superreview+
Attachment #173818 - Flags: review?(cbiesinger) → review+
(Assignee)

Updated

12 years ago
Attachment #173818 - Flags: approval1.7.6?
Attachment #173818 - Flags: approval-aviary1.0.1?
(Assignee)

Updated

12 years ago
Attachment #173818 - Flags: approval1.8b?
Comment on attachment 173818 [details] [diff] [review]
v1 patch

a=dveditz for 1.7 and 1.0.1 branches
Attachment #173818 - Flags: approval1.7.6?
Attachment #173818 - Flags: approval1.7.6+
Attachment #173818 - Flags: approval-aviary1.0.1?
Attachment #173818 - Flags: approval-aviary1.0.1+
Comment on attachment 173818 [details] [diff] [review]
v1 patch

a=caillon for 1.8beta
Attachment #173818 - Flags: approval1.8b? → approval1.8b+
(Assignee)

Comment 16

12 years ago
fixed-on-trunk, fixed-aviary1.0.1, fixed1.7.6
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Keywords: fixed-aviary1.0.1, fixed1.7.6
Resolution: --- → FIXED
(Assignee)

Updated

12 years ago
Flags: blocking-aviary1.1?

Comment 17

12 years ago
Verified fixed.  With testcase in comment #3, the address bar displays the
current bugzilla url and the lock icon shows the proper security info and cert
for mozilla.org.

Aviary Branch: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Gecko/20050217 Firefox/1.0

M18a/Trunk: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050217

M176 Branch: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050217
Status: RESOLVED → VERIFIED
Group: security
Created attachment 187619 [details] [diff] [review]
patch for 1.4 branch
Attachment #187619 - Flags: review?(cbiesinger)
Attachment #187619 - Flags: superreview?(bzbarsky)
Attachment #187619 - Flags: review?(cbiesinger) → review+
Attachment #187619 - Flags: superreview?(bzbarsky) → superreview+

Updated

11 years ago
Flags: testcase+

Updated

10 years ago
Flags: in-testsuite+ → in-testsuite?
You need to log in before you can comment on or make changes to this bug.