925878 - Favicon redirection should exhibit better caching behavior

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: Favicon Handling, defect)

Description

[Chris Kitching [:ckitching]]

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.

Comment 2

[:Margaret Leibovic]

Sebastian, do you think this is still something worth doing?

Comment 3

[Sebastian Kaspari (:sebastian; :pocmo)]

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.

Comment 4

[BMO Automation]

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.