Dominik Schmidt created TIKA-4825:
-------------------------------------
Summary: 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
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)
