[
https://issues.apache.org/jira/browse/TIKA-4825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18106024#comment-18106024
]
ASF GitHub Bot commented on TIKA-4825:
--------------------------------------
dschmidt commented on PR #3039:
URL: https://github.com/apache/tika/pull/3039#issuecomment-5346643305
Just wanted to bring it up, so you can decide because it's a slight
behavioral change. Fine with me either way :)
> 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)
