When modifying a request in the delegate method (Safari 4 beta) webView:resource:willSendRequest:redirectResponse:fromDataSource:, the cache policy is ignored. When setting it to NSURLRequestReloadIgnoringCacheData, the cache is still used for the request, even if you change the URL path in the modified request. The cache policy was followed in previous versions of WebKit. I found another person who came across the same issues, described in more detail here: http://lists.apple.com/archives/webkitsdk-dev/2009/Apr/msg00026.html
It would be great if you could provide a minimal test application, perhaps a trivial modification to the MiniBrowser sample application, that demonstrates the problem that you're experiencing. This will make it clear precisely what it is you're doing and will make it easier for us to investigate the problem.
Created attachment 30447 [details] Demo App for Bug
I attached an xcode project that illustrates the bug. When you open the app, it loads a document (test.html) that links to the CSS document, test.css. Initially, test.css specifies a red background for the document, which is what you see. After 10 seconds, test.css is updated to specify a blue background, and test.html is loaded again. However, with Safari 4 beta, the background stays red even though the cache policy for test.css is set to NSURLRequestReloadIgnoringCacheData. I tested the app with Safari 3, and the background correctly changes to blue. Let me know if you have any questions.
Have you tested this against a WebKit nightly build?
Thanks you for the demo application! I cannot reproduce this issue with a current WebKit build, and I suspect that it was fixed in <http://trac.webkit.org/changeset/41425>. You can find information about how to test and debug against nightly WebKit builds at <http://developer.apple.com/safari/articles/opensource/webkitnightlybuilds.html>.
Sounds good, Alexey. I downloaded the nightly and also tried it, and it worked correctly. I look forward to seeing this fix in the next Safari release (hopefully, soon?).
This also seems to be fixed in my testing with svn r43888. (Thought I'd mention that, since my mailing list post was referenced below.)
Actually, I can't reproduce this with Mac OS X 10.5.7 either (Safari 3.2.3). My previous tests were with Mac OS X 10.5.6. So I'd say it's already fixed in production.
Other comments suggest this worked fine in Safari 3.x and regressed in the Safari 4 Public Beta. Testing in Safari 3.2 doesn't confirm that this has been fixed.