[
https://issues.apache.org/jira/browse/TIKA-5050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18138381#comment-18138381
]
ASF GitHub Bot commented on TIKA-5050:
--------------------------------------
dschmidt opened a new pull request, #3546:
URL: https://github.com/apache/tika/pull/3546
[TIKA-5050](https://issues.apache.org/jira/browse/TIKA-5050)
EpubParser decoded manifest hrefs with `URLDecoder`, which decodes form
data, so `Text/c++.xhtml` became `Text/c .xhtml`, and appended them to the
OPF's folder without resolving `../`. Such spine items and images were skipped
silently.
`ZipEntryPaths.resolve(from, reference)` in tika-parser-zip-commons resolves
a URI reference against the entry holding it (RFC 3986, 5.2), percent-decodes
the path, drops the fragment, and refuses references with a scheme or authority
or leading above the package root. A reference that is not a valid URI (a raw
space) is taken as a literal path. EpubParser uses it for manifest hrefs and
for `encryption.xml`'s CipherReference URIs, so an escaped name still matches
when checking for encrypted items. The OPC thumbnail relationship in #3545 is
the next user.
Tests build EPUBs with `+`, `%20`, `../` and a fragment in hrefs, an escaped
cover, and escaped encrypted items; the two EPUB tests fail on the old parser.
18 real EPUBs (Project Gutenberg, public GitHub repositories) give the same
text, embedded documents and cover as before.
> EpubParser misses manifest items whose href holds a '+' or a '../'
> ------------------------------------------------------------------
>
> Key: TIKA-5050
> URL: https://issues.apache.org/jira/browse/TIKA-5050
> Project: Tika
> Issue Type: Bug
> Components: parser
> Reporter: Dominik Schmidt
> Priority: Major
>
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
