[
https://issues.apache.org/jira/browse/TIKA-4825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18106032#comment-18106032
]
ASF GitHub Bot commented on TIKA-4825:
--------------------------------------
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.
```
> tika-pipes drops the caller-supplied Content-Type before detection, so
> /unpack routing needs a filename
> -------------------------------------------------------------------------------------------------------
>
> Key: TIKA-4825
> URL: https://issues.apache.org/jira/browse/TIKA-4825
> Project: Tika
> Issue Type: Improvement
> Reporter: Dominik Schmidt
> Priority: Major
>
> When parsing through tika-pipes (e.g. the tika-server /unpack and /unpack/all
> endpoints, /async, /pipes), the parser is selected by content detection
> inside an out-of-process worker. A caller can influence which parser runs by
> supplying a filename (Content-Disposition / resource name), but supplying the
> correct Content-Type header alone does not work.
> Concrete case: NEF (Nikon raw) is TIFF-based and has no content magic of its
> own; image/x-raw-nikon is defined by a *.nef glob plus sub-class-of
> image/tiff. So by data alone a NEF detects as image/tiff and routes to
> TiffParser; only the filename yields image/x-raw-nikon and routes to the
> dedicated raw parser. A client that streams a NEF with Content-Type:
> image/x-raw-nikon but no filename still gets TiffParser.
> Root cause: PipesWorker.parseFromTuple starts a fresh Metadata for the
> fetch/detect step (deliberately isolated from the caller's tuple metadata,
> which is re-applied only at the very end) and carries only
> TikaCoreProperties.RESOURCE_NAME_KEY across that boundary. The caller's
> Content-Type, which TikaResource.fillMetadata does place into
> HttpHeaders.CONTENT_TYPE (and CONTENT_TYPE_USER_OVERRIDE), is dropped before
> detection. Core detection would actually honor it: MimeTypes.detect applies a
> Content-Type hint via applyHint, keeping it when it equals or specializes the
> magic-detected type. The failure is purely that the hint never reaches the
> worker's detection metadata. The masking is worsened by
> EmitHandler.injectUserMetadata re-writing the caller's Content-Type into the
> output afterwards, so the returned Content-Type reads correct even though the
> wrong parser ran.
> Proposed change: in PipesWorker, carry HttpHeaders.CONTENT_TYPE across the
> fresh-metadata boundary alongside the resource name, as a soft hint.
> Security consideration: carry only the soft hint (HttpHeaders.CONTENT_TYPE),
> NOT CONTENT_TYPE_USER_OVERRIDE / CONTENT_TYPE_PARSER_OVERRIDE. The soft hint
> is constrained by applyHint to types that equal or specialize the
> magic-detected type, so a caller can refine within the hierarchy (image/tiff
> -> image/x-raw-nikon) but cannot force an unrelated type. This grants no more
> routing power than the already-carried filename, and detection overwrites
> HttpHeaders.CONTENT_TYPE with the detected type before parsing, so no parser
> sees an unvalidated caller value. Carrying an override key, by contrast,
> would let a caller bypass detection unconditionally.
> Note: this softens the worker's deliberate metadata isolation for two fields;
> input welcome on whether the soft-hint scope is the right contract.
> Implemented with a unit test covering the carry (resource name + Content-Type
> carried, override key never carried, null/blank no-ops).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
