I looked at the code and couldn't figure out how to get the behavior
that I thought was correct.
I worked around this by resolving all of my resource references in the
page at the time that I render the page markup. That works, but it means
that I have to walk the DOM and look at every node, identify all of them
that can contain resource references, and resolve the references the
same way I would do if my willSendRequest delegate were called. It costs
me more time to parse and walk the DOM, and I have this uneasy feeling
that I might miss some element type that contains a resource reference.
I'd rather rely on the browser control to find them for me and call my
delegate.
This affects only the back/forward cache, which controls caching of
entire web pages so that you can do a "go back" faster. That's not
what's happening here.
The caching that's causing you trouble is the caching done in WebCore.
This cache is not properly expiring things. And this caching happens
before you get a willSendRequest: callback.
This is a bug in WebKit, and I don't know of a workaround. We plan to
fix the WebCore cache expiration in the next Safari update.
<-- snip -->
Could you tell me if this is indeed the (same) bug that is affecting me.
Best regards
Alan Shouls
Hi
I have had some problems posting this to the list - but it seems to
have worked.
I have also tried making copies of the images specified request, so
they are uniquely named on the fly and in the /tmp directory and
changed the response so that it 'points' to them. Still the cache
refuses to release it's grip
Alan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webkitsdk-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webkitsdk-dev/email@hidden
