Last Comment Bug 276720 - wrong behavior with "http/1.1 204 no content"
: wrong behavior with "http/1.1 204 no content"
Status: VERIFIED FIXED
[sg:fix]
: fixed-aviary1.0.1, fixed1.7.6
Product: Core
Classification: Components
Component: Security (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla1.8beta1
Assigned To: Darin Fisher
:
Mentors:
https://nexus.passport.com/
Depends on:
Blocks: lockicon
  Show dependency treegraph
 
Reported: 2005-01-01 18:34 PST by Mathieu Deaudelin-Lemay (previous account)
Modified: 2007-04-01 14:27 PDT (History)
10 users (show)
caillon: blocking1.7.6+
caillon: blocking‑aviary1.0.1+
asa: blocking1.8b+
bob: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Screenshot of this bug in Firefox 1.0 (35.58 KB, image/png)
2005-01-01 18:39 PST, Mathieu Deaudelin-Lemay (previous account)
no flags Details
Test page for this bug (1.03 KB, text/html)
2005-01-01 19:13 PST, Mathieu Deaudelin-Lemay (previous account)
no flags Details
v1 patch (1.77 KB, patch)
2005-02-08 18:36 PST, Darin Fisher
cbiesinger: review+
bzbarsky: superreview+
dveditz: approval‑aviary1.0.1+
dveditz: approval1.7.6+
caillon: approval1.8b+
Details | Diff | Splinter Review
patch for 1.4 branch (1.58 KB, patch)
2005-06-29 00:24 PDT, Nian Liu(n/a in a long time)
cbiesinger: review+
bzbarsky: superreview+
Details | Diff | Splinter Review

Description Mathieu Deaudelin-Lemay (previous account) 2005-01-01 18:34:56 PST
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.
Comment 1 Mathieu Deaudelin-Lemay (previous account) 2005-01-01 18:39:49 PST
Created attachment 170060 [details]
Screenshot of this bug in Firefox 1.0
Comment 2 Mathieu Deaudelin-Lemay (previous account) 2005-01-01 19:04:06 PST
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).
Comment 3 Mathieu Deaudelin-Lemay (previous account) 2005-01-01 19:13:49 PST
Created attachment 170061 [details]
Test page for this bug

This replaces the screenshot i had posted. sorry for all this spam.
Comment 4 Christian :Biesinger (don't email me, ping me on IRC) 2005-01-02 18:45:45 PST
fixed with bug 268483 maybe?
Comment 5 Christian :Biesinger (don't email me, ping me on IRC) 2005-01-02 18:48:04 PST
hm, obviously not - still seeing this in a trunk build (linux)
Comment 6 Daniel Veditz [:dveditz] 2005-01-03 00:17:19 PST
-> Darin
Comment 7 Boris Zbarsky [:bz] (TPAC) 2005-01-27 21:46:25 PST
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.
Comment 8 Darin Fisher 2005-01-27 22:39:21 PST
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).
Comment 9 Darin Fisher 2005-01-27 22:40:49 PST
forget i mentioned paypal... the fact that this can be used to spoof
passport.com sounds plenty serious to me.
Comment 10 Daniel Veditz [:dveditz] 2005-02-06 10:33:54 PST
This sounds an awful lot like the timing issues in several of the other lock
icon bugs. Will this fall out of those fixes?
Comment 11 Christopher Aillon (sabbatical, not receiving bugmail) 2005-02-07 12:07:15 PST
We need to get this one too on the branches.
Comment 12 Darin Fisher 2005-02-08 18:36:42 PST
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 :)
Comment 13 Boris Zbarsky [:bz] (TPAC) 2005-02-08 18:52:09 PST
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.
Comment 14 Daniel Veditz [:dveditz] 2005-02-09 13:51:00 PST
Comment on attachment 173818 [details] [diff] [review]
v1 patch

a=dveditz for 1.7 and 1.0.1 branches
Comment 15 Christopher Aillon (sabbatical, not receiving bugmail) 2005-02-09 15:29:11 PST
Comment on attachment 173818 [details] [diff] [review]
v1 patch

a=caillon for 1.8beta
Comment 16 Darin Fisher 2005-02-11 16:43:24 PST
fixed-on-trunk, fixed-aviary1.0.1, fixed1.7.6
Comment 17 Jay Patel [:jay] 2005-02-17 17:25:09 PST
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
Comment 18 Nian Liu(n/a in a long time) 2005-06-29 00:24:27 PDT
Created attachment 187619 [details] [diff] [review]
patch for 1.4 branch

Note You need to log in before you can comment on or make changes to this bug.