oscerd opened a new pull request, #25596: URL: https://github.com/apache/camel/pull/25596
# CAMEL-24422 `DoclingProducer.getInputPath()` decided what a `String` message body *meant* by inspecting its prefix: - `http://` / `https://` → handed to Docling as a remote URL to fetch - leading `/`, or an embedded `\` → read from the local filesystem - anything else → converted as document content The mode was chosen implicitly and the route author had no way to influence it. A route that means "convert whatever text arrives in the body" silently switched to reading a file when that text happened to begin with `/`. ## What changed **1. Intent is now expressible.** The two location readings are opt-in: | Option | Default | Effect when enabled | |---|---|---| | `allowUrlSource` | `false` | A body starting with `http://` / `https://` is fetched as a URL | | `allowFilePathSource` | `false` | A body starting with `/`, or containing `\`, is read from disk | | `inputBaseDirectory` | _(unset)_ | Local input paths must resolve inside this directory | Refusing to interpret a body names the option that would enable it. A body that is neither a URL nor a path is still converted as content, exactly as before. Only a **bare `String` body** is gated, because only it is ambiguous. The `CamelDoclingInputFilePath` header, `File` / `byte[]` / `InputStream` bodies, and the explicit path collections used by the batch operations (`List<String>`, `String[]`, `List<File>`, `File[]`) already state their meaning and keep working with no opt-in. This is what keeps the batch operations usable by default. `inputBaseDirectory` applies to all of them. Containment normalizes lexically and compares on path-segment boundaries — the same idiom as CAMEL-24279 — so a sibling directory sharing a name prefix with the base is not accepted. When the base directory is set, relative paths resolve against it and the validated path is the one used downstream, so the path that was checked is the path that is read. **2. Duplicated prefix logic removed.** The `http://` / `https://` test was implemented independently in four places (`getInputPath`, `addSourceToRequest`, `addSourceToChunkRequest`, `extractMetadataUsingApi` — the last spelling it negatively). All four now call one `isRemoteSource()` helper, so new handling cannot be added to some and missed in others. **3. `validateFileSize` → `validateFileSizeIfPresent`.** It was wrapped in `Files.exists()` and so silently skipped a path that resolved to nothing, while reading at the call site as though a check had happened. The name now shows that. Local input paths go through a new `validateLocalInputPath`, which requires the path to exist and reports a missing one as `File not found` before Docling is invoked. ## Compatibility This changes a default, so an upgrade-guide entry is included in `camel-4x-upgrade-guide-4_23.adoc`. A route that passes the document in the body is unaffected; a route that passes a URL or a path in the body must set the matching option. ## Testing - New `DoclingInputSourceValidationTest` (17 tests) covering both gates, the jail including traversal and the name-prefix sibling case, the header remaining ungated, the missing-path failure, and the batch String-vs-collection distinction. - `mvn test` on `camel-docling`: **66 tests, 0 failures**. - Full reactor `mvn clean install -DskipTests`: **696/696 BUILD SUCCESS**, with the regenerated catalog, component/endpoint DSL mirrors and security-options map committed. - The existing custom-argument test and the integration tests pass the input location in the body, and have been updated to opt in — the same migration users perform. `ChunkingIT` needed no change because it uses the header. --- 🤖 _Claude Code on behalf of @oscerd_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
