Prevent caching of byte range requests in zipped data for Safari and iOS

Steps to reproduce:
1) Clone and install the project from https://github.com/readium/readium-js-viewer
2) Use grunt to set up the server locally on 8080
3) In Safari on the Mac or iOS browse to the included example compressed .epub file: http://localhost:8080/simpleviewer.html?epub=epub_content/internal_link.epub

Expected Result:
The red "Cover Page" in the demo epub

Actual Result:
A blank page

Technical Details:
The problem is when zip.js is making the request for a byte range by adding the (example) headers If-Range:"21577-1395235757000", Range:bytes=866-1023 Safari is incorrectly returning the same "range" of bytes no matter what is specified in the headers.  Here's a few screenshots from Safari Dev Tools that may explain it more clearly than I am :)

First byte range request made:
![first_request](https://f.cloud.github.com/assets/382106/2476381/c9045f8a-b062-11e3-8a13-efb81395d764.png)


Second byte range request made:
![second_request](https://f.cloud.github.com/assets/382106/2476382/cbef6a28-b062-11e3-9855-c73d903e08e0.png)


Notice how Safari also incorrectly reports "No" in the "Cached" column even though the data is clearly being cached which is apparently a bug itself.

This doesn't present itself on unzipped epub content since it makes a full request (not byte range) for each document as it is needed.  Thankfully Safari honors the If-None-Match headers-- if added (and does not match the requested files etag) it will serve the correct data for the request and correct the issue.