Closed Bug 328605 Opened 19 years ago Closed 9 years ago

"Heuristic Expiration"(when no Cache-Control:max-age & no Expires:) is better to be discarded when session restart. Or too long "Heuristic Expiration" is to be avoided.

Categories

(Core :: Networking: Cache, enhancement)

Product:
Core
Component:
Networking: Cache
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 277813

People

(Reporter: World, Unassigned)

References

Details

Currently "Heuristic Expiration" is effective even after session restart. This cuases some user confusions like Bug 327438 when "When the page is out of date"(browser.cache.check_doc_frequency=3,default) and long "Heuristic Expiration". Some other bugs similar symptom seem to be report like Bug 327438. IE seems to ignore "Heuristic Expiration" when session resatrt. I think "Heuristic Expiration"(when no Cache-Control:max-age & no Expires:) is better to be discarded when session restart. This can be a solution for Bug 221036.
If request of comment #0 will be implemented, resolving Bug 310656 will become impossible... There is no way other than changing algorythm for "Heuristic Expiration"? (a) If very small, make it larger (relief of Bug 310656 case) (b) If very large, make it smaller (relief of Bug 327438 case) By the way, are there any good way to encourage lazy servers to provide explicit expiration time? RFC 2616 ( http://www.ietf.org/rfc/rfc2616.txt ) : > 13.2.2 Heuristic Expiration >(snip) and we encourage origin servers to provide explicit expiration times > as much as possible. > 14.46 Warning > 113 Heuristic expiration > MUST be included if the cache heuristically chose a freshness > lifetime greater than 24 hours and the response's age is greater > than 24 hours.
Can you tell me what is the difference between this bug and bug 221036? > By the way, are there any good way to encourage lazy servers to provide > explicit expiration time? No, because that would the require the people who place the images there to manually select an appropriate max-age value (which is completely unrealistic). The server cannot "guess" any better than the browser, so using server-side heuristics doesn't give us anything either. Note that 14.46 in RFC 2616 is about caching proxy servers, which is not relevant here.
The previous comment applies to all static content on the server, of course, not just images. Images are just a typical example.
(In reply to comment #2) > Can you tell me what is the difference between this bug and bug 221036? This is spin-off of Bug 221036, and opposite request to Bug 310656. "Unexpect cached data use" due to long "Heuristic Expiration" occurs in next 3 cases. (1) "Once per session"(browser.cache.check_doc_frequency=0) (1-1) On first access after session restart (2) "When the page is out of date"(browser.cache.check_doc_frequency=3 (2-1) On first access after session restart (2-2) Subsequent access durig a session Bug 221036 initially refered to (1-1) and (2-1), and (1-1) case is found to be Mozilla's bug. But (2-1) is uncertain whether bug or not. - I think this case is not bug. If (2-1) is bug, there is no reason to keep Bug 310656 open, since making "Heuristic Expiration" longer has no meaning if If-Modified-Since is always requested when first access after session restart. Then I opened this bug for this case with comment #0. I'd like to make it clear in this bug, instead of Bug 221036. Difference of this bug from Bug 221036 is "this bug covers (2-2) in addition to (2-1)", and it's comment #1, and opposite case to Bug 310656. Bugs like Bug 327438 are claim of "If-Modified-Since is not issued when (2-1) and (2-2)". If shorter "Heuristic Expiration", probablity of claim will decrease. Shorter "Heuristic Expiration" will improve (1-1) case too even if Bug 221036 is not fixed. Another minor reason why I splitted (2-1) case from Bug 221036. If (2-1) case is processed in Bug 221036, Bug 221036 will be contaminated by bold statements, I think.
(In addition to comment #4) Although Bug 221036 comment #0 refers to both (1-1) and (2-1), bug opener's saying is "cached data is used even when (1-1) as done in (2-1)". And he doesn't say "(2-1) is bug" from the first. He says "(1-1) is bug" only. See initial summary of Bug 221036.
Chaingig summary(add 'too long Heuristic is to be avoided', reflect comment #1).
Summary: "Heuristic Expiration"(when no Cache-Control:max-age & no Expires:) is better to be discarded when session restart → "Heuristic Expiration"(when no Cache-Control:max-age & no Expires:) is better to be discarded when session restart. Or too long "Heuristic Expiration" is to be avoided.
Definition of "too long" is very difficult: - When Bug 221036, "Heuristic Expiration" is 6 months. (Last-Modified: Tue, 26 Jun 2001 08:34:01 GMT. Intentional test?) - When Bug 323537, "Heuristic Expiration" is 16 minutes, but user says "doesn't update", so user's expectation is shorter than 16 minutes in this case.
Bug 271652 was external CSS file case.
(In addition to comment #8) Bug 271652 is report by client user, and reporter says that UI for cache option like Netscape/Mozilla/Seamonkey can be a solution for him. This indicates that default of browser.cache.check_doc_frequency=1 (Every time I view the page) can be a solution of Bug 328605's issue, unwanted claims by server management persons or client users.
*** Bug 331317 has been marked as a duplicate of this bug. ***
I've found bug for "too long Heuristic Expiration is to be avoided" part. > Bug 277813 : Auto-generated Expires date set too far into future
Depends on: 277813
A simple solution(enhancement, just an idea): - Introduce browser/cache.heuristic_expiration.max and browser/cache.heuristic_expiration.min - If "Huristic Expiraion">max Then change to max. Else If "Huristic Expiraion"<min Then change to mim.
Blocks: 352848
No longer blocks: 352848
FYI. "GET-requests with a query-url" case will be probably improved by Bug 468594.
Depends on: 468594
I'll add a max in 277813 and dup this to that
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.