Closed
Bug 120304
Opened 23 years ago
Closed 14 years ago
Favicons not cached for https sites
Categories
(Core :: Networking: Cache, defect)
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: tpowellmoz, Unassigned)
References
(Blocks 1 open bug, )
Details
Attachments
(1 file)
(deleted),
image/png
|
Details |
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.
Reporter | ||
Comment 1•23 years ago
|
||
Added example URL https://mail.yahoo.com (you may need to accept a certificate).
This is completely reproducable.
Comment 2•23 years ago
|
||
Over to Networking: Cache.
Assignee: asa → gordon
Component: Browser-General → Networking: Cache
QA Contact: doronr → tever
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
Comment 4•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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.
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Comment 7•22 years ago
|
||
*** 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
Comment 9•21 years ago
|
||
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•21 years ago
|
||
*** Bug 240326 has been marked as a duplicate of this bug. ***
Comment 11•21 years ago
|
||
*** Bug 188749 has been marked as a duplicate of this bug. ***
Comment 12•20 years ago
|
||
This bug still exists, even though the method of storing favicons has changed.
I can reproduce this on firefox branch build 20040726.
Comment 13•20 years ago
|
||
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•20 years ago
|
||
(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•15 years ago
|
||
I can't see this happening with Shiretoko and it's been 5 years. Close this one?
Updated•15 years ago
|
QA Contact: tever → networking.cache
Updated•15 years ago
|
Assignee: hyatt → nobody
Comment 16•15 years ago
|
||
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
Comment 17•14 years ago
|
||
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•14 years ago
|
||
Comment 19•14 years ago
|
||
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.
Description
•