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.

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).

This replaces the screenshot i had posted. sorry for all this spam.

fixed with bug 268483 maybe?

hm, obviously not - still seeing this in a trunk build (linux)

-> 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.

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).

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

This sounds an awful lot like the timing issues in several of the other lock icon bugs. Will this fall out of those fixes?

We need to get this one too on the branches.

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 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 on attachment 173818 [details] [diff] [review] v1 patch a=dveditz for 1.7 and 1.0.1 branches

Comment on attachment 173818 [details] [diff] [review] v1 patch a=caillon for 1.8beta

fixed-on-trunk, fixed-aviary1.0.1, fixed1.7.6

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