[
https://issues.apache.org/jira/browse/TIKA-4825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18105975#comment-18105975
]
ASF GitHub Bot commented on TIKA-4825:
--------------------------------------
dschmidt opened a new pull request, #3039:
URL: https://github.com/apache/tika/pull/3039
When parsing through tika-pipes (tika-server /unpack and /unpack/all,
/async, /pipes), a caller can steer parser selection by supplying a filename,
but supplying the correct `Content-Type` header alone does not work.
Example: NEF is TIFF-based with no content magic; `image/x-raw-nikon` is a
`*.nef` glob plus `sub-class-of image/tiff`. By data alone a NEF detects as
`image/tiff` (→ TiffParser); only the filename yields `image/x-raw-nikon`. A
client streaming a NEF with `Content-Type: image/x-raw-nikon` but no filename
still gets TiffParser.
Root cause: `PipesWorker.parseFromTuple` builds a fresh `Metadata` for
fetch/detection (deliberately isolated from the caller's tuple metadata) and
carries only `RESOURCE_NAME_KEY` across that boundary. The caller's
`Content-Type`, which `TikaResource.fillMetadata` does set, is dropped before
detection. Core detection would honor it: `MimeTypes.detect` applies a
`Content-Type` hint via `applyHint`, keeping it when it equals or specializes
the magic-detected type.
This change carries `HttpHeaders.CONTENT_TYPE` across the boundary alongside
the resource name, as a soft hint.
**Security:** only the soft hint is carried, deliberately **not**
`CONTENT_TYPE_USER_OVERRIDE`/`CONTENT_TYPE_PARSER_OVERRIDE`. `applyHint`
constrains the hint 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 would instead let a
caller bypass detection unconditionally.
This softens the worker's deliberate metadata isolation for two fields;
feedback welcome on whether the soft-hint scope is the right contract.
Unit test covers the carry: resource name and `Content-Type` carried,
override key never carried, null/blank no-ops.
> 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)
