Closed Bug 925878 Opened 8 years ago Closed 3 months ago
Favicon redirection should exhibit better caching behavior
Followup to Bug 914296. Rarely, websites will issue HTTP 302/303 status codes when serving favicons, causing us to follow a redirect chain to reach the real resource. When we finally get to the end of the chain (Assuming it's valid and not a cycle or such) we'll be some steps removed Location-wise from where we started. We should be recording the *fetched* favicon URL, and any 301 responses, in the DB and cache. We'll get better cache behavior as a result. The Location header indicates the real location of the favicon, and so in fact we should look in our cache for each new location, and do the right thing with loadsInFlight -- recursing! Any 302/303 responses are temporary, and so can be cached in a different way to essentially skip the redirect chain.
Summary: Favicon redirection could exhibit better caching behavoiur. → Favicon redirection should exhibit better caching behavior
Component: Theme and Visual Design → Favicon Handling
Hardware: ARM → All
Sebastian, do you think this is still something worth doing?
Right now I can't see why we'd want to store the whole URL/redirect graph in the database. But I'll come back to this while working on the meta bug.
We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.