1272587 - Add cache API to delete recent entries

Status: NEW

(Core :: Networking: Cache, defect, P3)

Description

[Jason Duell]

The immediate consumer here is Captive Portal (we want to make sure we don't store any incorrect cache entries that the Captive Portal feeds to us, and it may take a little while for us to determine we're in a captive portal).  That can just be a fixed short amount, like 5 or 10 minutes.

If it's possible, I think it would also be great to provide an API for deleting longer periods of time--the "clear recent history" button defaults to "last two hours", and also provides 1 hr, 4 hour, and "today".  Let's think about how hard/expensive it would be to try to support those (I'm guessing the hard part would be to support clearing these periods if the browser has been shut down during the period).  If we don't want to try to support the restart case, let's think about an algorithm that 1) keeps the info needed to delete recent cache entries up to some limit (either a number of entries, so we only use a fixed amount of RAM on this, or a fixed time period), and then we have an API that requests to clear an arbitrary amount of time, and we either delete that as requested, or delete the whole cache if we can't do just that interval.  (That sounds lame, but it would still be a big improvement over deleting the entire cache everytime someone requests a delete of the last hour, which is the status quo).

Comment 1

[Jason Duell]

If we keep some sort of record of the last time firefox closed (previous to the current run), we might be able to support "clear last hour" even if we've only been running for five minutes (i.e. if we know that the last hour contains only the existing 5 minute firefox fun).  This could capture a lot of use cases.

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

Jason, do you mean DOM Cache API or the http cache?

Comment 3

[Jason Duell]

Ben: This bug is for the HTTP cache.  I suppose the DOM cache could have the same issue if it's possible that it could populated with bogus replies from the captive portal (i.e. URI for "foo.com" containing hotel login page instead of foo.com's content).  Is that something we need to worry about?

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

I was just confused by the title since "cache API" usually refers to the dom cache and not HTTP cache.  Thanks for clarifying.

Comment 5

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 6

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 7

[Valentin Gosu [:valentin] (he/him) {{ PTO until Nov 5 }}]

Unassigning Michal to move bugs back to triage pool.

Comment 8

[Sunil Mayya]

Hey Valentin,
Do we still need this to implement this? Is it impactful enough for us to move it to the necko next?

Comment 9

[Valentin Gosu [:valentin] (he/him) {{ PTO until Nov 5 }}]

I'm not sure if this is impactful enough to be worth the effort.
As mentioned in comment 0, there are some scenarios where we'd might want to clear just a certain period of time, such as when leaving a captive portal network. In most other cases we just clear the the entire cache. This has the downside that if we do it too often, it will hurt performance.
The easy way to implement clearing just a time range would be to walk the entire cache, and clear by time range, but given the 2gb file limit, this could mean many thousands of files.
I think it's OK to leave it in the cache for now.