Better Safari Support

Data isn't served correctly due to a webkit bug that caches some byte range requests.  The problem only presents itself when you are viewing the contents of the epub directly by pulling out specific parts of the compressed epub on the fly.

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.