[
https://issues.apache.org/jira/browse/TIKA-4971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18129650#comment-18129650
]
Tim Allison commented on TIKA-4971:
-----------------------------------
My bot thinks you're in good enough stead?
```
Already compatible with 4.2.0
- Route: PUT /unpack/preset/thumbnail and the preset name are the same on
main. A preset that hasn't been activated still returns 404 in 4.2, which is
what the PR's error handling expects.
- No thumbnail: 4.2's preset sets emptyPackage: SKIP, so Tika answers 204,
and the PR treats 204 as "no thumbnail". On 4.1.0 the PR finds no image in the
zip and reaches the same result.
- Zip layout: in 4.2 the zip becomes a Frictionless package by default
(datapackage.json, rmeta.json, unpacked/…; TIKA-4681/4971). The PR picks the
image by its type rather than its path, so it doesn't care about the
layout change.
- Hints: it sends the filename in Content-Disposition and a type hint in
Content-Type. Tika uses both, and the mapping example
image/x-nikon-nef:image/x-raw-nikon uses real Tika type names.
Out of step with 4.2.0
- Config file no longer needed: with 4.2.0, TIKA_PRESETS=thumbnail (#3383,
merged today, by the same author) replaces the mounted config. The compose
files, the TikaURL description in config.go, the README and the 404
error message all still say "presets in its config". They could document
the env var for 4.2+ and keep the config file for 4.1.
- CI pins apache/tika:4.1.0-full: that release has the flat zip and no 204,
so the 4.2 behavior is never tested. Meanwhile devtools uses latest-full, which
becomes 4.2.0 at release.
- Raw formats that need 4.2.0: the advertised list includes image/x-epson-erf
and image/x-olympus-orf, but those previews come from TIKA-4980, which isn't in
4.1.0. The docs saying "needs Tika 4.1 or newer" therefore
overstate what 4.1 can do.
- Stale comment: in preprocessor/tika.go, thumbnailFromZip has two stacked
doc comments. entryContentType says "the preset zip carries no metadata
entries", which is false on 4.2. The image's type is also found from
the file extension, then Go's DetectContentType sniffer, and that sniffer
doesn't recognize TIFF. A TIFF thumbnail would be silently skipped. On 4.2 they
could read the mediatype from datapackage.json instead.
Operational concern, not checked
- Load: by default every non-image file goes to Tika, and Convert reads the
whole file into memory before uploading it, with a 60 s timeout. I didn't check
whether max_input_file_size applies before this step. If it
doesn't, every large video or archive is buffered and sent to Tika just to
look for a thumbnail.
```
> Make output from /unpack and -Z more equivalent
> -----------------------------------------------
>
> Key: TIKA-4971
> URL: https://issues.apache.org/jira/browse/TIKA-4971
> Project: Tika
> Issue Type: Task
> Reporter: Tim Allison
> Priority: Major
>
> There are a number of subtle differences that we should iron out.
> And we also need to fix some things so that these packages actually pass
> frictionless validation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
