This is an automated email from the ASF dual-hosted git repository. tballison pushed a commit to branch TIKA-4809-stage-3 in repository https://gitbox.apache.org/repos/asf/tika.git
commit fad8226c473e0dcbaf5dae14c3a287c0f5e08522 Author: tallison <[email protected]> AuthorDate: Sun Aug 9 19:54:22 2026 -0400 TIKA-4809: Document enableUnsecureFeatures removal and /meta's silent changes --- .../migration-to-4x/migrating-tika-server-4x.adoc | 44 +++++++++++++++++++++- docs/modules/ROOT/pages/security.adoc | 5 ++- 2 files changed, 46 insertions(+), 3 deletions(-) diff --git a/docs/modules/ROOT/pages/migration-to-4x/migrating-tika-server-4x.adoc b/docs/modules/ROOT/pages/migration-to-4x/migrating-tika-server-4x.adoc index 127d3508ff..3eda1ecd1d 100644 --- a/docs/modules/ROOT/pages/migration-to-4x/migrating-tika-server-4x.adoc +++ b/docs/modules/ROOT/pages/migration-to-4x/migrating-tika-server-4x.adoc @@ -135,6 +135,31 @@ for error text should check `tk:exception:container-exception` (full-object endpoints) or the `422` body (`/meta/\{field}`, populated only when `returnStackTrace=true`). +Two changes to the returned metadata come with this, neither of which produces an +error: + +* **`/meta` no longer returns a `language` field.** Language detection previously ran + inline on this endpoint via a dedicated content handler that buffered text solely to + detect the language, which meant holding the document text twice to populate one + field. That handler was removed. `/meta` deliberately parses with the `ignore` + content handler, so there is no text for a language detector to work from. ++ +**Migration:** configure a language-detection metadata filter +(`charsoup-metadata-filter`, `optimaize`, or `opennlp`) and use `/rmeta` or +`/tika/json`, which capture content. The detected value arrives as +`tk:detected-language`, with `tk:detected-language-confidence`. Note that these +filters read `tk:content`, so they are no-ops on `/meta` and on any endpoint +configured with the `ignore` handler. + +* **`/meta` now sets `tk:exception:embedded-depth-limit-reached` on any document + with embedded content.** `/meta` suppresses embedded parsing by setting an embedded + depth limit of `0`, and reaching a limit is recorded. The previous implementation + suppressed embedded documents by a different mechanism that recorded nothing. The + flag is expected on this endpoint and does not indicate a truncated result. ++ +**Migration:** clients that alert on the presence of any `tk:exception:*` key should +exclude this one for `/meta`. + === Accept Header Routing Removed The `/tika` endpoint no longer routes based on `Accept` headers. Use explicit paths instead: @@ -157,7 +182,24 @@ The following `TikaServerConfig` options have been removed: === `/pipes` and `/async` Require `allowPipes`; Per-Request Config Requires `allowPerRequestConfig` -Previously these endpoints (and per-request parser configuration) were enabled simply by listing endpoints under `server.endpoints`. The capabilities are now split into two default-`false` flags in the `server` section: +This replaces the `enableUnsecureFeatures` flag that alpha-1 briefly used, and before +that, enabling these capabilities simply by listing endpoints under `server.endpoints`. +`enableUnsecureFeatures` no longer exists: a config that still carries it fails to start +with an "Unrecognized field" error naming the key, rather than silently ignoring it. +The single flag has been split into two, so that granting batch/fetcher access and +granting per-request parser configuration are separate decisions: + +|=== +|Was |Now + +|`enableUnsecureFeatures: true` (to use `/pipes` or `/async`) +|`allowPipes: true` + +|`enableUnsecureFeatures: true` (to send per-request config) +|`allowPerRequestConfig: true` +|=== + +The capabilities are two default-`false` flags in the `server` section: * `allowPipes` gates the `/pipes` and `/async` endpoints, which drive process-isolated batch parsing through your fetchers and emitters. Selecting either without `allowPipes` causes the server to refuse to start with a clear error. * `allowPerRequestConfig` gates per-request parser configuration: the `/config` family of endpoints and the multipart `config` part. When off, such requests are rejected with 403. diff --git a/docs/modules/ROOT/pages/security.adoc b/docs/modules/ROOT/pages/security.adoc index 044c221a3d..c2b043225b 100644 --- a/docs/modules/ROOT/pages/security.adoc +++ b/docs/modules/ROOT/pages/security.adoc @@ -56,8 +56,9 @@ and `allowComponentManagement` — the latter lets clients add, modify, and dele and read back stored configs, which can contain secrets — are off by default. Run it only behind network controls and, ideally, mutual TLS. See xref:using-tika/grpc/index.adoc[Tika gRPC]. -For the upgrade from the former `enableUnsecureFeatures` flag, see -xref:migration-to-4x/migrating-tika-server-4x.adoc[Migrating tika-server to 4.x]. +For the upgrade from the former `enableUnsecureFeatures` flag, which is now split into +`allowPipes` and `allowPerRequestConfig`, see +xref:migration-to-4x/migrating-tika-server-4x.adoc#_pipes_and_async_require_allowpipes_per_request_config_requires_allowperrequestconfig[Migrating tika-server to 4.x]. == Known Vulnerabilities
