mrdevel2002-ui opened a new pull request, #3516: URL: https://github.com/apache/tika/pull/3516
`GDALParser` runs `gdalinfo` on the document's temp file, and GDAL chooses its driver from the file's content rather than from the type Tika detected. The VRT and GTI (raster tile index) drivers accept any file whose first kilobyte merely contains `<VRTDataset` or `<GDALTileIndexDataset`, so an ASCII-headed format that Tika routes to `GDALParser` can carry one. A FITS header (`SIMPLE = T`) followed by a VRT whose `SourceFilename` is `/vsicurl/http://host/...`, `http://host/...` or `WMS:http://host/...` is detected as `application/fits`, which only `GDALParser` claims, and `gdalinfo` then sends HEAD/GET requests to whatever host the document names. GDAL's `HTTP response code: 404` style errors land in `ExternalProcess.STD_ERR`, so whoever reads the metadata also gets a status oracle for internal addresses. The GTI variant behaves the same on GDAL 3.9 and later, and skipping VRT alone does not stop it. `restrictEnvironment` adds `VRT GTI` to `GDAL_SKIP` for the `gdalinfo` process, appended to any `GDAL_SKIP` the operator already exports, and sets `CPL_VSIL_CURL_ALLOWED_FILENAME` to empty so no `/vsicurl/` name opens through any other driver; the input here is always a local temp file, so nothing legitimate needs one. I put it in the process environment rather than in `--config` arguments so it also covers an operator-supplied `command` template. The trade-off: Tika has no detection for `.vrt` or GTI files, so neither driver serves a type that reaches this parser through `AutoDetectParser`, but a caller that forces `application/vrt` onto `GDALParser` no longer gets VRT metadata. On GDAL older than 3.9, which has no GTI driver, `gdalinfo` also logs a one-line "Unable to find driver GTI" warning to stderr. A real FITS file (`WFPC2u5780205r_c0fx.fits`) still opens with the FITS driver and the same output. `testDocumentCannotPointGdalinfoAtAUrl` parses a FITS-headed VRT and a FITS-headed GTI that point at a loopback `ServerSocket` and asserts nothing connects; like the other GDAL tests it is skipped when `gdalinfo` is not installed, so CI skips it. I ran `TestGDALParser` in an `ubuntu:resolute` container with `gdal-bin` 3.12.2, the base and package Tika's full Docker image uses. Without the `restrictEnvironment` call the new test fails with `expected: <0> but was: <8>`; with it all six tests pass, including the existing netCDF and FITS parsing tests. `testOperatorGdalSkipIsKept` runs without GDAL. `./mvnw clean apache-rat:check install -Pci` of tika-parser-scientific-module (tests, checkstyle, spotless, forbidden-apis, rat) is green. - [ ] open issue on the Tika issue tracker: not filed yet, happy to open one or have it linked - [ ] issue ID in the PR title and commit message: pending the issue above - [x] commits are squashed into a single one - [x] Tika builds and unit tests pass with `./mvnw clean install` (affected module) - [x] generative AI tool used: this fix was found and prepared with AI assistance (Claude Code) and reviewed by me before submitting; the commit carries `Generated-by:` per the ASF Generative Tooling Guidance. - [x] no conflicts with the recent `main` branch - [ ] new downstream module added to `tika-bom/pom.xml`: not applicable -- 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]
