Bug 51286 – Image cache not cleared by no-cache XHR

• Status: NEW
• Component: Page Loading

[Nathan Vander Wilt]

According to RFC 2616 13.10 ( http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10) , "some HTTP methods MUST cause a cache to invalidate an entity" including POST. However, issuing a POST to a URL via XMLHTTPRequest fails to cause WebKit to invalidate its cache for the requested URL. This prevents dynamic web pages from using a POST to invalidate resources (such as images) that are known by the client side scripts to have been updated.

[Nathan Vander Wilt]

Apparently this used to work in Safari circa early 2006:
http://www.mnot.net/blog/2006/02/18/invalidation

[Nathan Vander Wilt]

I've been poking at this some more, and can't quite figure out what's going on. As far as XHR is concerned, WebKit *does* do proper cache invalidation. It seems like there's some sort of DOM cache actually causing the issue I'm having.

We use AJAX to load a server-generated form into a dialog. This form displays an image from a static URL, and the user can update the image at this URL via the form. However, when the form is fetched again later the image display is the old image. This makes sense, because as far as the browser knows the image has not been updated (only the form URL has been POSTed to).

So to work around this, I tried to use XHR to POST to the image URL, as well as send a GET with Cache-Control: no-cache. These behave as expected, but when I fetch the dialog HTML and add it to the DOM, I still get the old image. This is the bug.

There is, however, one way I can get the new image to show while debugging: if I open the dialog HTML directly in a new window, it has the new image. If I *then* show the dialog in context (without doing anything to refresh the main app page) it too gets the new image.

I understand I can use a variety of methods and tricks to avoid cache this image, but the client should be able to successfully have the rendered DOM update when the cache is manually invalidated through JavaScript.

[Alexey Proskuryakov]

Would it be possible for you to publish an example URL that shows this problem? This report doesn't appear actionable with the information currently present in it.

[Nathan Vander Wilt]

Here is a test case for the issue:
http://andyet.couchone.com/share/_design/webkitBug51286/index.html


To reproduce:
1. Click "Create" to add a dynamically generated div containing an image that has a random color each time it is fetched. Note this image color.
2. Click "Remove" to remove this div/image from the DOM.
3. Click "Clear" to send an XHR request for the image URL with "Cache-Control: no-cache" header set to force end-to-end reload (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4).
4. Click "Create" to dynamically generate a new image div. Compare this image color to the one noted in step #1.

Expected results:
New image div is a different color because any local cache stored in step #1 was invalidated in step #3.

Actual results:
New image div is the same color ini step #4 as it was in step #1.

[Alexey Proskuryakov]

Thanks, that makes good sense. Yes, XMLHttpRequest doesn't affect WebCore memory cache now.

[Alexey Proskuryakov]

See also: bug 52153.

[Alexey Proskuryakov]

This is probably fixed now, as XHR uses the memory cache.