Closed dysbulic closed 3 years ago
Unfortunately, the HTTP response's Content-Type
header is application/zip
instead of application/epub+zip
.
Furthermore, there is no Content-Disposition
header in the HTTP response, which could be used to provide a .epub
file extension (e.g. attachment; filename="book_QmfZEJiQBhWmHLhP5ZDnV2CijF7R88Qp8iqn5g5qy7SCSD.epub"
).
curl -s -L -I -X GET "http://ipfs.io/ipfs/QmfZEJiQBhWmHLhP5ZDnV2CijF7R88Qp8iqn5g5qy7SCSD"
=>
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 23 Dec 2019 12:11:04 GMT
Content-Type: application/zip
Content-Length: 925398
Connection: keep-alive
Accept-Ranges: bytes
Access-Control-Allow-Methods: GET
Cache-Control: public, max-age=29030400, immutable
Etag: "QmfZEJiQBhWmHLhP5ZDnV2CijF7R88Qp8iqn5g5qy7SCSD"
Last-Modified: Thu, 01 Jan 1970 00:00:01 GMT
Suborigin: ipfs000bciqp7t5cu2kfpjdvnfyg5ij4lydumy7w7xoccn4v23c3wqq3ql2zncq
X-Ipfs-Gateway-Host: gateway-bank1-ams1
X-Ipfs-Path: /ipfs/QmfZEJiQBhWmHLhP5ZDnV2CijF7R88Qp8iqn5g5qy7SCSD
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: X-Requested-With, Range, Content-Range, X-Chunked-Output, X-Stream-Output
Access-Control-Expose-Headers: Content-Range, X-Chunked-Output, X-Stream-Output
X-IPFS-POP: gateway-bank1-ams1
Same problem with another IPFS content source:
https://cloudflare-ipfs.com/ipfs/QmQDVpWjjmbkssmNt5Qe3zMmn69Cnx1nVpptgtBbuq21Kc/2019
=>
curl -s -L -I -X GET "https://cloudflare-ipfs.com/ipfs/QmQDVpWjjmbkssmNt5Qe3zMmn69Cnx1nVpptgtBbuq21Kc/2019/Linux-Journal-2019-08.epub"
=>
HTTP/2 200
date: Mon, 23 Dec 2019 14:08:22 GMT
content-type: application/zip
set-cookie: __cfduid=d708bd644dd632aaaf64a655eedd6df0f1577110102; expires=Wed, 22-Jan-20 14:08:22 GMT; path=/; domain=.cloudflare-ipfs.com; HttpOnly; SameSite=Lax
cf-ray: 549ae83b6d4bce13-LHR
access-control-allow-origin: *
age: 5293
cache-control: public, max-age=29030400, immutable
etag: W/"QmXzZ23GrYy4TknQWjh8n9VE8vvLNuFTCjma5pod4phzqW"
last-modified: Thu, 01 Jan 1970 00:00:01 GMT
vary: X-Ipfs-Secure-Gateway, Accept-Encoding
cf-cache-status: HIT
access-control-allow-headers: Content-Type
access-control-allow-headers: Range
access-control-allow-headers: User-Agent
access-control-allow-headers: X-Requested-With
access-control-allow-methods: GET
access-control-expose-headers: Content-Range
access-control-expose-headers: X-Chunked-Output
access-control-expose-headers: X-Stream-Output
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
suborigin: ipfs000bciqbxysbxlts6pxmhmmwujmztlyxzzkn7ti7dbqbbcixqapyhtshaxy
x-ipfs-path: /ipfs/QmQDVpWjjmbkssmNt5Qe3zMmn69Cnx1nVpptgtBbuq21Kc/2019/Linux-Journal-2019-08.epub
server: cloudflare
Also note that as the HTTP response headers Access-Control-Allow-Headers
and Access-Control-Expose-Headers
do not include Content-Length
, this makes it impossible for certain clients to leverage Accept-Ranges: bytes
(i.e. HTTP 1.1 partial requests), thereby forcing a fallback on downloading the entire EPUB file instead of "streaming" small resource fragments.
Have you solved your problem?
Honestly, I switched to Readium.
Hello, May I ask, were you able to use Readium with IPFS?
I am building a collection on books stored in IPFS. Files are identified by a hash rather than a name.
There are several ways to set up access, but the simplest is through the gateway on
ipfs.io
. Hashes can be resolved to files through a url of the form:http://ipfs.io/ipfs/HASH
whereHASH
is a value likeQmfZEJiQBhWmHLhP5ZDnV2CijF7R88Qp8iqn5g5qy7SCSD
.I created a set of supplemental presets, and added
http://ipfs.io
totrustworthy-origins
and*
toextract-if-necessary
.When I try to load a page with a URL like
http://localhost:61671/bibi/?book=http://ipfs.io/ipfs/QmfZEJiQBhWmHLhP5ZDnV2CijF7R88Qp8iqn5g5qy7SCSD
it tries to open a manifest on the server a couple times, which fails, then at the top of the page I get an error"Failed to open the book. Failed to open as both EPUB file and EPUB folder."
My assumption is it is being caused by the lack of a filename despite the wildcard for extracting.