Bug 82672 - [Mac] XHR range requests are broken; affects pdf.js (Test failure: http/tests/xmlhttprequest/range-test.html)
Summary: [Mac] XHR range requests are broken; affects pdf.js (Test failure: http/tests...
Status: RESOLVED DUPLICATE of bug 144682
Alias: None
Product: WebKit
Classification: Unclassified
Component: XML (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar, LayoutTestFailure
Depends on:
Blocks:
 
Reported: 2012-03-29 15:48 PDT by Enrica Casucci
Modified: 2015-07-03 10:01 PDT (History)
15 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Enrica Casucci 2012-03-29 15:48:39 PDT
Not sure when this started.
Adding to skip list. Please remove when this is fixed.
Comment 1 Radar WebKit Bug Importer 2012-03-29 15:49:23 PDT
<rdar://problem/11150946>
Comment 2 Simon Fraser (smfr) 2012-09-19 16:07:54 PDT
Still fails.
Comment 3 Alexey Proskuryakov 2012-09-20 09:36:49 PDT
I suspect that CFNetwork is not giving us 206 responses when it already has complete ones cached.
Comment 4 Hugh Winkler 2012-12-22 10:48:14 PST
A workaround for this bug is to suppress caching for each XHR with a Range header, using:

xhr.setRequestHeader('Cache-control", "no-cache");
Comment 5 David Kilzer (:ddkilzer) 2013-06-12 10:20:52 PDT
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)
Comment 6 David Kilzer (:ddkilzer) 2013-06-12 10:38:45 PDT
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
Comment 7 Paolo Martini 2014-02-26 15:33:15 PST
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.
Comment 8 Alexey Proskuryakov 2014-10-27 11:27:02 PDT
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.
Comment 9 Silvia Pfeiffer 2014-11-09 15:55:52 PST
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.
Comment 10 Silvia Pfeiffer 2014-11-09 16:00:36 PST
Note there is a similar issue with the Vary header:
https://bugs.webkit.org/show_bug.cgi?id=71509
Comment 11 Brion Vibber 2014-11-09 16:13:02 PST
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.)
Comment 12 Brion Vibber 2015-07-02 06:21:49 PDT
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...
Comment 13 David Kilzer (:ddkilzer) 2015-07-03 08:45:26 PDT
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>).
Comment 14 David Kilzer (:ddkilzer) 2015-07-03 08:46:14 PDT
Marking as forward dupe for tracking purposes.

*** This bug has been marked as a duplicate of bug 144682 ***
Comment 15 Brion Vibber 2015-07-03 10:01:51 PDT
(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>).