1170556 - Preserve HTTP cached content for back and forth capability (document expired error)

Status: NEW

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

Description

[Honza Bambas (:mayhemer)]

Under some circumstances (small HTTP cache, memory only HTTP cache) users may experience Document Expired error page when navigating back or forward between pages that are results of POSTs (may also affect GETs.)

This happens because cache entries for POST results are quickly evicted based on our complex eviction mechanisms.

We should try to find some way to keep cache entries vital for BF navigation alive.  There is the SetForceValid(seconds) method on nsICacheEntry that may do what we need.  There are tho three questions:
- where to engage it (on navigation completion probably)
- where to drop it when no longer needed (docshell goes away probably)
- keep an entry indefinitely or what time we should use to keep an entry (it's only per-session, so after browser restart entries may be deleted anyway)

Based on feedback from bug 1079789.

Comment 1

[fireattack [:fireattack]]

What's the difference between this bug and bug 1060082?

It sounds totally the same, except that one is supposed to be fixed with bug 1079789.

Comment 2

[Honza Bambas (:mayhemer)]

(In reply to Benjamin Peng from comment #1)
> What's the difference between this bug and bug 1060082?
> 
> It sounds totally the same, except that one is supposed to be fixed with bug
> 1079789.

Because that one has been fixed (duplicated) with the patches from bug 1079789.  Reopening long ago closed bugs is not a good practice.

Comment 3

[fireattack [:fireattack]]

(In reply to Honza Bambas (:mayhemer) from comment #2)
> (In reply to Benjamin Peng from comment #1)
> > What's the difference between this bug and bug 1060082?
> > 
> > It sounds totally the same, except that one is supposed to be fixed with bug
> > 1079789.
> 
> Because that one has been fixed (duplicated) with the patches from bug
> 1079789.  Reopening long ago closed bugs is not a good practice.

You missed my point: my question is what the difference is between these two. 

I mean, that one is already fixed. So I guess this one has slightly different cause or behavior from that? Would you provide a website which we can reproduce this "new" bug?

Comment 4

[fireattack [:fireattack]]

I can't reproduce the bug with steps from comment 39 in bug 1079789. But I didn't use 1MB cache, I use 350MB and test when it's full.

The reason I didn't use 1MB cache is it counters the statement the user who reported this bug made in comment 41:

"That said, if the cache is full, shouldn't it simply throw away the oldest one and make place for a new page? Or am I getting this wrong?"

That is exactly the behavior I encountered. My cache is already full, but it can still cache the previous visited page for me to go back. So I have no problem (there WAS a problem, like I reported in bug 1060082).

His/her testing with 1MB cache is questionable, at least not related to aforementioned statement.  What if the page itself is already larger than 1MB? Firefox has no way to cache it if it's larger than your cache capacity, right? It has nothing to do with cache full or not, more like the MAX capacity is just too small.

Comment 5

[Honza Bambas (:mayhemer)]

(In reply to Benjamin Peng from comment #3)

> I mean, that one is already fixed. So I guess this one has slightly
> different cause or behavior from that? Would you provide a website which we
> can reproduce this "new" bug?

They are probably the same.  I just wanted to have a new clearly defining bug.  There STRs in various duplicate bugs.  Just look for them ;)

(In reply to Benjamin Peng from comment #4)
> I can't reproduce the bug with steps from comment 39 in bug 1079789. But I
> didn't use 1MB cache, I use 350MB and test when it's full.
> 
> The reason I didn't use 1MB cache is it counters the statement the user who
> reported this bug made in comment 41:
> 
> "That said, if the cache is full, shouldn't it simply throw away the oldest
> one and make place for a new page? Or am I getting this wrong?"
> 
> That is exactly the behavior I encountered. My cache is already full, but it
> can still cache the previous visited page for me to go back. So I have no
> problem (there WAS a problem, like I reported in bug 1060082).
> 
> His/her testing with 1MB cache is questionable, at least not related to
> aforementioned statement.  What if the page itself is already larger than
> 1MB? Firefox has no way to cache it if it's larger than your cache capacity,
> right? It has nothing to do with cache full or not, more like the MAX
> capacity is just too small.

I know there is a way to evict cache entries even though they are 'new'.  And these could be important for bf navigation.  Please remember that 'oldest' is no longer the criteria for eviction.  It's 'least used' + some more soft conditions.

With a 1MB cache you are right we won't cache much.  The entry size limit is even smaller then 1MB then.

I somehow understood this was still easily reproducible even with larger cache.  Anyway, I know there is zero protection to keep entries vital for bf navigation.  Hence this bug.

It's not critical, I just want to have this potential issue tracked.

Comment 6

[fireattack [:fireattack]]

(In reply to Honza Bambas (:mayhemer) from comment #5)
> (In reply to Benjamin Peng from comment #3)
> 
> > I mean, that one is already fixed. So I guess this one has slightly
> > different cause or behavior from that? Would you provide a website which we
> > can reproduce this "new" bug?
> 
> They are probably the same.  I just wanted to have a new clearly defining
> bug.  There STRs in various duplicate bugs.  Just look for them ;)
> 
> (In reply to Benjamin Peng from comment #4)
> > I can't reproduce the bug with steps from comment 39 in bug 1079789. But I
> > didn't use 1MB cache, I use 350MB and test when it's full.
> > 
> > The reason I didn't use 1MB cache is it counters the statement the user who
> > reported this bug made in comment 41:
> > 
> > "That said, if the cache is full, shouldn't it simply throw away the oldest
> > one and make place for a new page? Or am I getting this wrong?"
> > 
> > That is exactly the behavior I encountered. My cache is already full, but it
> > can still cache the previous visited page for me to go back. So I have no
> > problem (there WAS a problem, like I reported in bug 1060082).
> > 
> > His/her testing with 1MB cache is questionable, at least not related to
> > aforementioned statement.  What if the page itself is already larger than
> > 1MB? Firefox has no way to cache it if it's larger than your cache capacity,
> > right? It has nothing to do with cache full or not, more like the MAX
> > capacity is just too small.
> 
> I know there is a way to evict cache entries even though they are 'new'. 
> And these could be important for bf navigation.  Please remember that
> 'oldest' is no longer the criteria for eviction.  It's 'least used' + some
> more soft conditions.
> 
> With a 1MB cache you are right we won't cache much.  The entry size limit is
> even smaller then 1MB then.
> 
> I somehow understood this was still easily reproducible even with larger
> cache.  Anyway, I know there is zero protection to keep entries vital for bf
> navigation.  Hence this bug.
> 
> It's not critical, I just want to have this potential issue tracked.

Cheers. 

Totally agree there could still be potential issue that old (not oldest) cache doesn't get evicted to make space for better bf navigation (although after we fixed bug 1079789, it happens very RARELY at least for me). 

My only concern is that 1MB set is not a good practice to prove that :)

Comment 7

[Firefox Bug Husbandry Bot]

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

Comment 8

[Firefox Bug Husbandry Bot]

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