You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A typical "fetcher" URL in the current implementations would look like: https://r2.org/moby-dick.epub/chapter1.xhtml
Now, in my opinion, this is slightly "wrong", because the full path in the EPUB container is actually EPUB/chapter1.xhtml (regardless of its zipped / unzipped status).
Furthermore (and more importantly), we have a problem with relative paths such as: manifest>item@href => ../cover.jpg
...which would result in URLs such as:
https://r2.org/moby-dick.epub/../cover.jpg
(as you can see, the .. notation interferes because it is not escaped)
So, wouldn't it be better to logically follow the EPUB container file structure?
i.e.: https://r2.org/moby-dick.epub/cover.jpg https://r2.org/moby-dick.epub/EPUB/chapter1.xhtml
Your suggestion should handle two problematic situations:
accessing META-INF/encryption.xml
accessing cover.jpg
For EPUB/navdoc/toc.html and EPUB/smil/chapter1.smil do you calculate everything based on the relative path of the Navigation Document, NCX and SMIL?
The Navigation Document would reference ../chapter1.html but with your suggested change, we would have to indicate EPUB/chapter1.html in the manifest.
Same idea for NCX and SMIL.
I can't remember if in EPUB content documents, links can start with a / with for example:
<ahref="/EPUB/chapter1.html" />
That specific case would be very problematic because the navigator would attempt to access https://r2.org/EPUB/chapter1.html instead of https://r2.org/moby-dick.epub/EPUB/chapter1.html.
Let's say:
META-INF/container.xml
rootfile@href
=>EPUB/package.opf
manifest>item@href
=>chapter1.xhtml
A typical "fetcher" URL in the current implementations would look like:
https://r2.org/moby-dick.epub/chapter1.xhtml
Now, in my opinion, this is slightly "wrong", because the full path in the EPUB container is actually
EPUB/chapter1.xhtml
(regardless of its zipped / unzipped status).Furthermore (and more importantly), we have a problem with relative paths such as:
manifest>item@href
=>../cover.jpg
...which would result in URLs such as:
https://r2.org/moby-dick.epub/../cover.jpg
(as you can see, the
..
notation interferes because it is not escaped)So, wouldn't it be better to logically follow the EPUB container file structure?
i.e.:
https://r2.org/moby-dick.epub/cover.jpg
https://r2.org/moby-dick.epub/EPUB/chapter1.xhtml
Note that I implemented support for both syntaxes in the NodeJS streamer, as described here:
https://github.com/edrlab/r2-streamer-js/wiki/Demonstration#epub-resource-urls
The text was updated successfully, but these errors were encountered: