Closed Bug 46825 Opened 24 years ago Closed 24 years ago

cache should re-check server whenever not back/forward

Categories

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

Product:
Core
Component:
Networking: Cache
Type:
defect

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: ekrock, Assigned: neeti)

References

Details

(Whiteboard: [nsbeta3+]) 

[Copied this text over from bug 46741, which is a Bugzilla bug. This bug will
track the Necko vs. Nav4 cache behavioral incompatibility issue; bug 46741 will
track whatever separate Bugzilla problem I may have uncovered at the same time.]

It appears that the Necko cache works differently in some way than 4.x, causing
Bugzilla to behave differently in a way the user notices (and which is
inconvenient). I'm concerned that if this incompatibility causes noticeable
behavioral differences in Bugzilla, it may affect other web
apps/services/servers as well.

Text copied over from bug 46741:

Using Commercial 2000072508 on WinNT 4.0 SP4.

I'm seeing a suspiciously large number of mid-air collisions reported today by
Bugzilla. And now I have one where there's no evidence that someone else was
really changing the bug at the same time. I see this error message:

Mid-air collision detected! Someone else has made changes to this bug at the
same time you were trying to. The changes made were:
[ and then there are the who what etc. table headers, but no body cells!]

Also, on the Throw away link, I see this text:
Throw away my changes, and go revisit bug 3373233732

Note that bug # is shown twice.

... and when I click to submit anyway, I get this error message:

Content-type: text/html
Software error:
INSERT INTO bugs_activity (bug_id,who,bug_when,fieldid,oldvalue,newvalue) VALUES
(18895,3845,,39,'19608,22254,26508,33732','19608,22254,26508,33732,8388607'):
You have an error in your SQL syntax near
'39,'19608,22254,26508,33732','19608,22254,26508,33732,8388607')' at line 1 at
globals.pl line 134. Please send mail to this site's webmaster for help.

------- Additional Comments From ekrock@netscape.com 2000-07-27 18:51 -------

Upping severity to major as data loss occurred because of software error--will
have to retype my comments.

------- Additional Comments From David Baron 2000-07-27 19:36 -------

If you modify a bug once and then don't reload before modifying again, it will
look like a midair collision to bugzilla because of the way our cache works
(i.e., differently from 4.x in a way I haven't bother to figure out...).  Could
that have happened.
Nominating nsbeta3 and raising to critical.  I am investigating right now to
figure out what exactly the difference is.
Severity: normal → critical
Keywords: nsbeta3
Some tests (editing pages live on a server) revealed the problem is very simple:

In Nav 4.x (with the "Once Per Session" cache pref, the default), if a page is
being loaded at a new position in the session history, it is always re-validated
(a HEAD request, I would guess) from the server.  If it is re-displayed at an
existing position in session history (i.e., displayed using back/forward), the
server is not checked.

In other words, if the user goes to the page any way other than back/forward, we
should go back to the server.  However, if the user is using back/forward, we
should *not* go back to the server because it is too slow.

This is the behavior users expect and web sites depend on, so IMO it should be
the default in Mozilla as well.
Summary: difference in Necko cache vs. 4.x cache causes Bugzilla mid-air collision → cache should re-check server whenever not back/forward
In 4.x, if the cache preference is "Never", the page is not re-validated from
the server when the user creates a new position in session history for it.  So
this behavior should apply to the "Once Per Session" and "Always" cache prefs,
but not the "Never" one.
In testing 4.x, I am unable to distinguish the "Once Per Session" and "Always"
cache preferences.  They behave identically.  (Perhaps the difference could be
that "Always" always revalidates from the server with GET rather than HEAD??? 
Just a guess though...)

BTW, my testing of 4.x is all in Linux communicator 4.72.
DUP of bug 46338.

*** This bug has been marked as a duplicate of 46338 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
This is not a dup of 46338, because it has nothing really to do with form
submission.  It does affect form submission, but my testing did not involve form
submission at all.  Reopening.

This bug  says it's a bug that we don't reload when not using back/forward.
Bug 46338 says it's a bug that we do    reload when     using back/forward and
post data is involved.  (Perhaps caused by non-caching of posted data.)

Bug submission uses post, I think, but loading a bug report itself is a GET
request (and thus cacheable).
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
For the record, I'm seeing the same behavior in win32 Mozilla 2000-08-02-21-M18 
as I was in Linux builds last week:  that "Once Per Session" is incorrectly 
being treated as exactly that, and pages are not rechecked at the server when 
loaded into a new spot in session history.
OS: Windows NT → All
Hardware: PC → All
Depends on: 47400, 47401
Whiteboard: [nsbeta3+]
this should get fixed once the Tom finishes up the tests and Neeti verify's the 
correct behaviour (bug 47400) marking as dependent.
Status: REOPENED → ASSIGNED
testing this --> please ignore
testing
testing again
testing
If you modify a bug once and then don't reload before modifying again, it looks
look like a midair collision to bugzilla and nav4.x.

The problem in bugzilla was bug 46014, when a bug was modified and the link to 
revisit the bug was clicked "Go TO Bug#####" was clicked, we would get the old 
version of bug, and not the modified version. This has been fixed.

Neeti
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This is partly fixed, but not completely.  We still don't reload the page when a
page is the current thing that is "forward", but you click on a link to it
instead of hitting forward.  4.x reloaded the page in that case.
David,

Can tell me the steps to reproduce the problem you described in your comments 
above?

Thanks,
Neeti
1) Create two files on a web server where you can modify the files.  Call them A
and B.  Put in A a link to B
2) Load A
3) Click on B
4) Hit back
5) Modify page B
6) Click on B

In 4.x, you see the modifications, but in Mozilla you don't.
I did that exact test in my apache server. I dont see B reloaded in 4.71 when I
hit back and clicked on link to B after modifying B. I did the test on linux.

I do see a different problem. If I see any html file, modify it and hit reload,
I see the modification. But when I go Back and then forward, I see the old
content. I is like the cache never got updated with the content that came in
after the reload.
- 
Here is what I see on cache's data not getting updated on reload. The cache
recordID has changed. But the data hasn't been updated nor is modifiedtime,
updatetime. The CachedNetData entry is still the same.

Maybe this is a separate bug and we should mark this bug invalid unless David
Baron is pretty sure netscape 4.71 fetches the page on click of B.
I do see 4.75 on Linux reload B with the steps I described above with my cache
pref set to either "Every Time" or "Once Per Session".

The bug with the cache not using the newest data loaded sounds like bug 40049,
which is marked as fixed.
40049?  I don't know about that but this sounds similar/related to bug 38244.
On win32 of Communicator 4.7, I do not see B reloaded when I
hit back and clicked on link to B after modifying B.  Regarding the other 
problem of cache never getting updated with the content that came in
after the reload, which dp mentioned, it looks like bug 40449.

Neeti
Ok I have taken the reload issue to another bug 50619

let us keep this bugs to should page get updated on link click. We know
- 4.5 does
- 4.7 doesn't

Any help with what ie, 4.0 did would be good to know. Any volunteers ?
IE 5.0 doesn't check either. I am going to say this is the intended behaviour.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → INVALID
Owner/reporter, mark this 'verified', if applicable, thanks.

verified Invalid
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.