tballison commented on PR #3039:
URL: https://github.com/apache/tika/pull/3039#issuecomment-5346813789
claude has some input. let me know what you think.
```
1. HIGH — the NEF example only works if PR #3037 merges first. At this
PR's head, image/x-raw-nikon (tika-mimetypes.xml:7234) has no
sub-class-of image/tiff — the PR description's claim that it does is
wrong for main today; #3037 is what adds it. Standalone, applyHint
rejects the hint and a NEF still detects as image/tiff, so the headline
example in CHANGES and the carryCallerHints javadoc silently does
nothing. Two reviewers found this independently; I verified both files.
Fix: merge-order note (or land the sub-class-of here), and an e2e test
of the real-mime-database refinement case — nothing currently catches
this.
2. MEDIUM — CHANGES endpoint list is materially incomplete. Every parse
endpoint routes through parseFromTuple: /tika, /meta, /rmeta and
variants (the PR's own testMeta flipping 404→422 proves /meta), plus
tika-grpc and embedded PipesForkParser users. Listing only /unpack,
/unpack/all, /async, /pipes misleads upgraders — Copilot's /unpack/all
fix was cosmetic; the real gap remains.
3. MEDIUM — undocumented 3.x→4.x downgrade in the migration doc. In 3.x
the header was a hard override (CONTENT_TYPE_USER_OVERRIDE); now it's
refine-only. A 3.x client forcing text/plain onto arbitrary bytes gets
silently different behavior. migrating-tika-server-4x.adoc:427-430 says
Content-Type "still influences detection" — true post-PR but hides the
override→hint change. One paragraph fixes it.
4. MEDIUM — no negative-path tests for the security boundary. Nothing
asserts a non-specializing or garbage Content-Type is ignored — the
exact property the javadoc calls security-critical. A future applyHint
change could turn the hint into an override with nothing failing. Also:
for magic-less bytes everything specializes application/octet-stream,
so the hint effectively wins there — "only refines within the
hierarchy" is overstated in CHANGES (equal to filename power, so
acceptable, but say it).
5. MEDIUM — CHANGES entry sits in the already-rc'd "Release 4.0.0 -
8/18/2026" section, which rc1 froze without it (main is now
4.0.1-SNAPSHOT). If rc1 passes, released 4.0.0 won't contain TIKA-4825
while CHANGES claims it does. Correct only if you sink rc1 and respin —
which is exactly what dschmidt is asking you in the PR thread.
6. LOW — pre-existing, newly exposed: the carried value reaches
MimeTypes.forName, which registers every distinct syntactically-valid
unknown type into an unbounded map (slow memory growth under
adversarial unique types). Pre-existing on direct server endpoints;
this PR adds the pipes tuple path. Real fix is a non-registering lookup
in MimeTypes.detect — separate JIRA, not this PR.
7. LOW — cleanups: fillMetadata still stamps CONTENT_TYPE_USER_OVERRIDE
(TikaResource.java:263,341) which the worker now deliberately discards
— dead and misleading, natural companion cleanup. testMeta's 422 body
is unasserted (old test asserted the body; one assertContains closes
it). The 4-line call-site comment in parseFromTuple restates the
javadoc — trim to one line per repo policy.
```
--
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]
