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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
