Bug 82672

<rdar://problem/11150946>

Still fails.

I suspect that CFNetwork is not giving us 206 responses when it already has complete ones cached.

A workaround for this bug is to suppress caching for each XHR with a Range header, using: xhr.setRequestHeader('Cache-control", "no-cache");

When running the layout test (and deleting the line in LayoutTests/platform/mac/TestExpectations that expects a failure), this is how the test fails: --- layout-test-results/http/tests/xmlhttprequest/range-test-expected.txt +++ layout-test-results/http/tests/xmlhttprequest/range-test-actual.txt @@ -1,9 +1,11 @@ Test Range support in XMLHttpRequest getRange(resources/reply.xml, 34, 36, false) -Length : expected 2 got 2 +Expected a 206 response, got 200 +Length : expected 2 got 68 getRange(resources/reply.xml, 35, 38, false) -Length : expected 3 got 3 +Expected a 206 response, got 200 +Length : expected 3 got 68 getRange(resources/reply.xml, 34, 36, true) Length : expected 2 got 2 getRange(resources/reply.xml, 35, 38, true)

Yesterday at WWDC, a developer asked a question about pdf.js being broken for Mac Safari 6.0.x and Safari for iOS 6.x. I believe this may be the bug that's causing that issue. These are the relevant pdf.js bugs and commits that track the issue: Pdf.js not working in safari browser on MAC OSX 10.8.2, safari version 6.0.1 https://github.com/mozilla/pdf.js/issues/3260 Does not work on Safari mobile https://github.com/mozilla/pdf.js/issues/3262 Disable range request loading for safari. https://github.com/mozilla/pdf.js/pull/3315 https://github.com/brendandahl/pdf.js/commit/e6dadaadb8137f4e157fbcf565dba0ff68de627e Failing in Safari https://github.com/mozilla/pdf.js/issues/3352 https://github.com/mozilla/pdf.js/commit/152e376971c55f2d9058e6e4647b79e535afde6b

I've just finished a long debugging session on a product that uses XHR range requests to fetch particular files from zip archives hosted on the server. I found a new work-around for the Safari bug. It has been tested and verified working on: - OS X Mountain Lion - Safari Version 6.0.5 (8536.30.1) - OS X Mavericks - Safari Version 7.0.1 (9537.73.11) - iOS 7.0.6 (11B651) The problem: the second request to the same file for a different range returns the same contents as the first one. Safari wrongly reports "Cached: no" in the relevant line of the network tab of the developer tools. It also ignores "pragma=no-cache" headers, if added. The solution: I succeeded in making it throw away the old request by making each request unique. I accomplished this by generating a random string and adding the following header: If-None-Match: "<random string>". After this change Safari began returning the right contents from the new specified range of the file. This should let the web developers deploy a new and better work-around for their products instead of resorting to disabling range requests altogether. I also hope it can help the webkit developers in pin-pointing where this problem stems from.

This tests passes on Yosemite with both WK1 and WK2. But it still fails in Safari. This may mean that HTTP caching is somehow broken in regression tests on Yosemite, which hides the problem.

Note that https://github.com/gildas-lormeau/zip.js/pull/91/files uses the following header as a work-around: xhr.setRequestHeader("If-None-Match", "webkit-no-cache"); which may be more interoperable with other browsers.

Note there is a similar issue with the Vary header: https://bugs.webkit.org/show_bug.cgi?id=71509

I've found that this bug can at least be easily detected at runtime by checking the HTTP status code and Content-Range response header against the expected values. You can then issue a second request with caching disabled and continue on, without hardcoding assumptions about User-Agent strings. In ogv.js <https://github.com/brion/ogv.js/commit/9ab5bce2f99f13a82a07ab83eeae77ede031e620> I'm using such a check to only apply cache-busting if the bug is actually encountered. At least on OS X 10.10 I'm seeing the bug only after reaching the *end* of the file; so for the ogv.js media player case this doesn't hit until a second playthrough, unless the file is missing index information in which case a seek to the end is used to calculate the duration before playback begins. (Note I'm using a query-string as cache-buster so that the request will still be cacheable on the server-side proxy cache; though not ideal it seems to be working.)

I'm getting the same behavior in a native iOS app using NSURLConnection to download chunks with a Range: header, so this indeed seems to be a low-level CFNetwork caching issue...

WebKit has a new network cache, and this bug is fixed in that implementation via: Bug 144682: Network Cache: Layout Test http/tests/xmlhttprequest/range-test.html is failing <https://bugs.webkit.org/show_bug.cgi?id=144682> Please try WebKit Nightly build at <http://nightly.webkit.org/> to verify. We're still tracking the NSURLCache issue via Radar (<rdar://problem/11150946>).

Marking as forward dupe for tracking purposes. *** This bug has been marked as a duplicate of bug 144682 ***

(In reply to comment #13) > WebKit has a new network cache, and this bug is fixed in that implementation > via: > > Bug 144682: Network Cache: Layout Test > http/tests/xmlhttprequest/range-test.html is failing > <https://bugs.webkit.org/show_bug.cgi?id=144682> > > Please try WebKit Nightly build at <http://nightly.webkit.org/> to verify. Looks good with a current nightly -- my workaround from comment 11 gracefully disables itself. Thanks! > We're still tracking the NSURLCache issue via Radar > (<rdar://problem/11150946>).