[
https://issues.apache.org/jira/browse/TIKA-5036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18139100#comment-18139100
]
ASF GitHub Bot commented on TIKA-5036:
--------------------------------------
tballison commented on PR #3539:
URL: https://github.com/apache/tika/pull/3539#issuecomment-6665764911
Bot nits below. It also recommended testing on actual files, which you may
have done. Getting ASL v2 examples is hard. Let me know if you want me to try
to find files in commoncrawl.
```
Edge cases
1. The detector reads 136 KB from every input
(BlenderDetector.java:56-62). readNBytes(MAX_PREFIX_LENGTH) runs before
anything checks for gzip or zstd magic, so every file Tika detects pays
for a 136 KB read and allocation that is useless
unless it's compressed. Peek 4 bytes first and return OCTET_STREAM
unless they are 1f 8b or 28 b5 2f fd, the way
GZipSpecializationDetector does.
2. Gzip-compressed .blend detection depends on class-name order. In
CompositeDetector, a later result only replaces an
earlier one if it is a specialization of it. With the full standard
package:
- GZipSpecializationDetector returns application/gzip.
- BlenderDetector returns application/x-blender, which is not a
subclass of gzip.
- x-blender wins today only because detect.blender sorts before
detect.gzip. Swap the order, or add a user detector, and
it comes back as application/gzip.
The cad-module tests don't load the pkg module, so they can't see this.
Ask for a test in
tika-parsers-standard-integration-tests that detects a gzip-compressed
and a zstd-compressed blend with the full
DefaultDetector. Ideally, also make the result independent of order.
3. The parser never closes its decompressing wrapper
(BlenderParser.java:95). The ZstdInputStream or GZIPInputStream that
BlendCompression.open returns is left open, so zstd's native context
and the Inflater live until GC. Wrap tis in
CloseShieldInputStream and close in with try-with-resources.
Worth asking the author
- zstd window size on hostile input (plausible, not verified): the
detector now starts zstd decompression on every zstd
input. A frame header can declare a large window, and zstd-jni's default
cap is 2^27 (128 MB native).
ZstdInputStream.setLongMax(...) set to something small should cover
Blender's frames. CompressorParser already has this
exposure at parse time; this adds it at detect time.
```
> Blender and SketchUp: emit the embedded preview
> -----------------------------------------------
>
> Key: TIKA-5036
> URL: https://issues.apache.org/jira/browse/TIKA-5036
> Project: Tika
> Issue Type: Improvement
> Components: mime, parser
> Reporter: Dominik Schmidt
> Priority: Major
>
> {{.blend}} files carry a {{TEST}} block with an RGBA preview, {{.skp}} files
> an embedded PNG. Emitting it as THUMBNAIL gives both a preview.
> Both need media types first, see TIKA-3992. Note that {{.skp}} is registered
> as {{application/vnd.koan}} (SSEYO Koan), which SketchUp files collide with.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
