Closed Bug 120304 Opened 23 years ago Closed 14 years ago

Favicons not cached for https sites

Categories

(Core :: Networking: Cache, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
Future

People

(Reporter: tpowellmoz, Unassigned)

References

(Blocks 1 open bug, )

Details

Attachments

(1 file)

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.
Added example URL https://mail.yahoo.com (you may need to accept a certificate). This is completely reproducable.
Blocks: 120352
Over to Networking: Cache.
Assignee: asa → gordon
Component: Browser-General → Networking: Cache
QA Contact: doronr → tever
No longer blocks: 120352
Blocks: 113430
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?
Assignee: gordon → hyatt
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
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.
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.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Blocks: 120352
*** Bug 174724 has been marked as a duplicate of this bug. ***
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
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.
*** Bug 240326 has been marked as a duplicate of this bug. ***
*** Bug 188749 has been marked as a duplicate of this bug. ***
This bug still exists, even though the method of storing favicons has changed. I can reproduce this on firefox branch build 20040726.
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://
(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.
I can't see this happening with Shiretoko and it's been 5 years. Close this one?
QA Contact: tever → networking.cache
Assignee: hyatt → nobody
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.
Status: ASSIGNED → NEW
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.
Attached image Screenshot from comment 17 (deleted) —
SeaMonkey 2.1 now uses the favicon service. Closing as WORKSFORME.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: