dschmidt commented on PR #3539: URL: https://github.com/apache/tika/pull/3539#issuecomment-6666855531
Thanks, addressed in the last commit. 1. The detector reads the four magic bytes first and goes on only for zstd. 2. Right, it only worked by class name order. gzip blends are now recognized in `GZipSpecializationDetector`, the way warc.gz is, and `BlenderDetector` handles zstd only, where nothing else competes. `BlenderDetectionTest` in tika-parsers-standard-integration-tests detects gzip and zstd blends with the full `DefaultDetector` and with `CompositeDetector` in both orders; with the old detectors, gzip first gives `application/gzip`. 3. `BlenderParser` now closes the decompressing stream, with the input wrapped in `CloseShieldInputStream`. On the zstd window at detect time: I'd rather measure before capping it, as a small `setLongMax` could cut off real Blender files. Happy to look into it if you want it here. As for real files: the PR description lists what I ran it against (19 files from Blender 2.77 to 4.2, plain, gzip and zstd, and 25 from Blender 5.x, from public GitHub repositories); they still give the same results. None has a license that would let it go into the repo, so the tests build their files. If you find ASL-friendly ones in Common Crawl, I'd gladly add one. -- 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]
