[
https://issues.apache.org/jira/browse/TIKA-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18109526#comment-18109526
]
Dominik Schmidt commented on TIKA-4858:
---------------------------------------
Two ways to fix this: merge the sibling keys next to parse-context into the
context (400 if a key appears in both places), or reject any mix with a 400 and
document one form. I lean towards merging since the docs show the bare form for
/tika/config/json, but it is an API question, so which do you prefer? I can do
either.
> tika-server: a parse-context wrapper in the multipart config part silently
> drops its sibling keys
> -------------------------------------------------------------------------------------------------
>
> Key: TIKA-4858
> URL: https://issues.apache.org/jira/browse/TIKA-4858
> Project: Tika
> Issue Type: Bug
> Reporter: Dominik Schmidt
> Priority: Major
>
> ParseContextDeserializer.readParseContext treats the JSON either as
> {"parse-context": {...}} or as a bare map of components. A request part like
> {"pdf-parser": {...}, "parse-context": {"standard-unpack-selector": {...}}}
> therefore applies the selector and silently ignores pdf-parser; the caller
> sees no error, only a parse without the requested setting.
> The server documentation shows the bare form (-F
> "config={\"pdf-parser\":...}" for /tika/config/json) and the wrapped form
> (UnpackerResource javadoc), but never says they cannot be mixed. Either
> accept siblings next to the wrapper (merge them into the context) or reject
> the request with 400, and document the rule.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
