(split from bug 3810) From -[WebFrameBridge syncLoadResourceWithURL:customHeaders:postData:finalURL:responseHeaders:statusCode:] : // Never use cached data for these requests (xmlhttprequests). [request setCachePolicy:[[[self dataSource] request] cachePolicy]]; From Web Applications spec draft: UAs may set the If-Modified-Since, If-None-Match, If-Range, and Range headers if the resource is cached and has not expired (as allowed by HTTP), and must not allow those headers to be overridden. <...> In particular, UAs must not automatically set the Cache-Control or Pragma headers to defeat caching. Sounds like WebKit is violating the spec (although beware that it's a draft with many known issues). Worse, the current behavior seems to prevent any kind of caching - NSURLConnection is forbidden to do the caching internally, and conditional headers set by the calling code (which is not currently forbidden) make the request fail, because NSURLConnection unsuccessfully tries to process the 304 response itself. Or maybe the comment in WebFrameBridge is just misleading :)
Created attachment 6790 [details] proposed patch OK, my tests show that caching of XMLHttpRequest responses does work properly (in Safari with current WebKit builds, at least). Just don't add an If-Modified-Since header manually, and NSURLConnection will take care of the rest, and will return a 200 response. It returns a cached response if possible, or issues a conditional request if re-validation is needed. If this doesn't work for Dashboard widgets, which I haven't checked, then perhaps Dashboard always forces a reload of the main document, which defeats caching of subresources and XMLHttpRequests. Dashboard is closed source, so you'd need to file a bug via <http://bugreport.apple.com>. I think this comment is stale, the patch just removes it.
Mass moving XML DOM bugs to the "DOM" Component.