WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED DUPLICATE of
bug 144682
82672
[Mac] XHR range requests are broken; affects pdf.js (Test failure: http/tests/xmlhttprequest/range-test.html)
https://bugs.webkit.org/show_bug.cgi?id=82672
Summary
[Mac] XHR range requests are broken; affects pdf.js (Test failure: http/tests...
Enrica Casucci
Reported
2012-03-29 15:48:39 PDT
Not sure when this started. Adding to skip list. Please remove when this is fixed.
Attachments
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2012-03-29 15:49:23 PDT
<
rdar://problem/11150946
>
Simon Fraser (smfr)
Comment 2
2012-09-19 16:07:54 PDT
Still fails.
Alexey Proskuryakov
Comment 3
2012-09-20 09:36:49 PDT
I suspect that CFNetwork is not giving us 206 responses when it already has complete ones cached.
Hugh Winkler
Comment 4
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");
David Kilzer (:ddkilzer)
Comment 5
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)
David Kilzer (:ddkilzer)
Comment 6
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
Paolo Martini
Comment 7
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.
Alexey Proskuryakov
Comment 8
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.
Silvia Pfeiffer
Comment 9
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.
Silvia Pfeiffer
Comment 10
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
Brion Vibber
Comment 11
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.)
Brion Vibber
Comment 12
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...
David Kilzer (:ddkilzer)
Comment 13
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
>).
David Kilzer (:ddkilzer)
Comment 14
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
***
Brion Vibber
Comment 15
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
>).
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug