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).

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.

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

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?

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

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

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