120304 - Favicons not cached for https sites

Status: RESOLVED WORKSFORME

(Core :: Networking: Cache, defect)

Description

[Tim Powell]

The favicon will show up in your bookmarks after you visit the site, but if you
shut down and restart the browser, it is gone. Other favicons remain.

Go to an HTTPS site that has a favicon.
Bookmark the site. (Notice the favicon)
Shut down the browser.
Restart browser.
Notice that favicon is missing from bookmark, but that other bookmarks still
have favicon.

As I understand it, https sites are intentionally not cached for security.
Perhaps this points out a need for a separate cache just for favicons (if there
isn't one) so that it would be safe to cache the favicons but not impact other
cache code.

Noticed with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7+)
Gecko/20011228.

Comment 1

[Tim Powell]

Added example URL https://mail.yahoo.com (you may need to accept a certificate).
This is completely reproducable.

Comment 2

[Oliver Klee]

Over to Networking: Cache.

Comment 3

[gordon]

Favicons are cached separately from other documents, though they use the same
mechanism.

Hyatt, what's your opinion on whether we should persistently save favicons for
https sites, or why it doesn't seem to be working currently?

Comment 4

[Brendan Eich [:brendan]]

I hope https special casing of cache-control, recently checked in, doesn't have
any unwanted effects here.  Gordon, cc'ing you as well as darin.

/be

Comment 5

[Darin Fisher]

this probably doesn't have anything to do with the recent cache-control policy
changes.  HTTPS content has never been persistently cached.  this policy has
always been enforced by the HTTP code for security reasons.

now, as far as favicons are concerned, perhaps these icons should be fetched
using HTTP instead?  of course, it's not guaranteed that every HTTPS server will
have a corresponding HTTP server, but i suspect that many would.  the HTTPS link
could be tried if the HTTP link fails.  of course, that just adds more network
traffic, so i'm not sure that it is the right thing either.

Comment 6

[Darin Fisher]

oh, and of course there is the possibility of modifying the http code to allow a
client to enable persistent caching on a per channel basis.  there currently is
no API for such a thing.

Comment 7

[Asa Dotzler [:asa]]

*** Bug 174724 has been marked as a duplicate of this bug. ***

Comment 8

[athakur]

I'm experiencing an annoying bug that looks like a side effect of this.  It
happens if the favicon on the HTTPS site is part of a password protected folder.
 In some cases, when I open up a bookmark folder that has a link to this HTTPS
site, it will pop up  an authentication dialog when trying to refresh the favicon.

Here's what I do:
1.  Go to a password protected HTTPS site and save a bookmark
2.  Quit the browser
3.  Load the browser and go to the bookmark folder where you made the bookmark
4.  An authentication popup will come up

Comment 9

[Sergey Sokoloff]

Anand Thakur, there's Bugzilla Bug 133755 which summary (username/password
dialog when having favicons from password protected sites in bookmarks) exactly
matches your complain. Probably you should comment there.

Comment 10

[Alex Hirzel]

*** Bug 240326 has been marked as a duplicate of this bug. ***

Comment 11

[Alex Hirzel]

*** Bug 188749 has been marked as a duplicate of this bug. ***

Comment 12

[Thomas Rutter]

This bug still exists, even though the method of storing favicons has changed. 
I can reproduce this on firefox branch build 20040726.

Comment 13

[Steffen Wilberg]

WFM with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040726
Firefox/0.9.1+ (Steffen) since I removed all old-style favicons from my
bookmarks.html, i.e. those starting with ICON="http://

Comment 14

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #12)
> This bug still exists, even though the method of storing favicons has changed. 
> I can reproduce this on firefox branch build 20040726.

since it only changed in firefox, that is probably a firefox-specific bug. file
a firefox bug.

Comment 15

[d]

I can't see this happening with Shiretoko and it's been 5 years. Close this one?

Comment 16

[Michael Kohler [:mkohler]]

This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.

Comment 17

[RNicoletto]

I can reproduce a similar behavior with SeaMonkey 2.0.11 on Windows XP.
Step to reproduce: 
1. Go to an HTTPS site that has a favicon (https://online.unicreditbanca.it/login.htm).
2. Bookmark the site.

Result: NO favicon.

I cannot reproduce with Firefox 3.6.13 on Windows XP.

Comment 18

[RNicoletto]

Attachment: Screenshot from comment 17

Comment 19

[Philip Chee]

SeaMonkey 2.1 now uses the favicon service. Closing as WORKSFORME.