Closed
Bug 87710
Opened 24 years ago
Closed 24 years ago
Image cache does not re-validate images before reusing them...
Categories
(Core :: Networking: HTTP, defect, P3)
Core
Networking: HTTP
Tracking
()
RESOLVED
FIXED
mozilla0.9.2
People
(Reporter: rpotts, Assigned: darin.moz)
References
()
Details
(Whiteboard: checked in on trunk, critical for 0.9.2 - blizzard will check in)
Attachments
(4 files)
884 bytes,
patch
|
Details | Diff | Splinter Review | |
1.17 KB,
patch
|
Details | Diff | Splinter Review | |
13.35 KB,
patch
|
Details | Diff | Splinter Review | |
13.34 KB,
patch
|
Details | Diff | Splinter Review |
Currently, once an image is cached, it is never revaildated with the server.
THis means that if the image was the result of dynamic content on the server
(ie. the same image URL returns different images for each request) only the
initial image will be displayed.
This bug was spun off from bug #69855 once all of the other issues were resolved.
Reporter | ||
Comment 1•24 years ago
|
||
Oops, that should have been bug #68955 :-)
Comment 2•24 years ago
|
||
my code:
if (mCacheEntry && chan) {
nsCOMPtr<nsICachingChannel> cacheChannel(do_QueryInterface(chan));
if (cacheChannel) {
nsCOMPtr<nsISupports> cacheToken;
cacheChannel->GetCacheToken(getter_AddRefs(cacheToken));
if (cacheToken) {
nsCOMPtr<nsICacheEntryDescriptor>
entryDesc(do_QueryInterface(cacheToken));
if (entryDesc) {
PRUint32 expiration;
/* get the expiration time from the caching channel's token */
entryDesc->GetExpirationTime(&expiration);
/* set the expiration time on our entry */
mCacheEntry->SetExpirationTime(expiration);
}
}
}
}
gets 0 back from the http channel's get expiration time. this is an http bug.
(or the website not giving an expire time bug)
Assignee: pavlov → neeti
Component: ImageLib → Networking: HTTP
QA Contact: tpreston → benc
Assignee | ||
Comment 4•24 years ago
|
||
-> mozilla 0.9.2 (hopefully)
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla0.9.2
Assignee | ||
Comment 5•24 years ago
|
||
Assignee | ||
Comment 6•24 years ago
|
||
Assignee | ||
Comment 7•24 years ago
|
||
Assignee | ||
Comment 8•24 years ago
|
||
both patches are required to fix the problem.
Assignee | ||
Comment 9•24 years ago
|
||
the trick to my patches are to set the cache expiration time appropriately so
that imagelib will be forced to ask http for the data at the right time.
Comment 10•24 years ago
|
||
+ if (mResponseHead->MustRevalidate() == PR_FALSE) {
-> if (!mResponseHead->MustRevalidate()) {
r=bbaetz with that change
Assignee | ||
Comment 11•24 years ago
|
||
Comment 12•24 years ago
|
||
sr=jst
Assignee | ||
Comment 13•24 years ago
|
||
checked in on trunk
Keywords: patch
Whiteboard: checked in on trunk
Comment 14•24 years ago
|
||
Is this something that we want in 0.9.2, too?
Assignee | ||
Comment 15•24 years ago
|
||
blizzard: yes
Updated•24 years ago
|
Whiteboard: checked in on trunk → checked in on trunk, critical for 0.9.2 - blizzard will check in
Comment 16•24 years ago
|
||
Hey darin. If it's the right fix then it's the right fix, but I think this
change unwound the ``mysterious miracle speedup'' from last week. For
certain, Mac times on the trunk have popped up to ~2400 on today's trunk build
from ~2100 on the branch on cached page loads. We might want to track down what
the dynamics of this are.
Comment 17•24 years ago
|
||
Checked into the 0.9.2 branch as well. John, if you're worried about the
performance of this then you should open another bug for that information. I
need to close this for tracking.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•