[
https://issues.apache.org/jira/browse/TIKA-4873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18111014#comment-18111014
]
Hudson commented on TIKA-4873:
------------------------------
SUCCESS: Integrated in Jenkins build Tika ยป tika-main-jdk17 #1609 (See
[https://ci-builds.apache.org/job/Tika/job/tika-main-jdk17/1609/])
TIKA-4873 - give embedded documents their size (#3117) (github:
[https://github.com/apache/tika/commit/5b78cd84bce98bfb9e8eea2f9b942ad0a4aeb2a0])
* (edit)
tika-parsers/tika-parsers-standard/tika-parsers-standard-modules/tika-parser-image-module/src/main/java/org/apache/tika/parser/image/RawTiffParser.java
* (add)
tika-core/src/test/java/org/apache/tika/extractor/EmbeddedContentLengthTest.java
* (edit) CHANGES.txt
* (edit)
tika-core/src/main/java/org/apache/tika/extractor/ParsingEmbeddedDocumentExtractor.java
* (edit)
tika-parsers/tika-parsers-standard/tika-parsers-standard-modules/tika-parser-audiovideo-module/src/main/java/org/apache/tika/parser/audio/CoverArt.java
* (edit)
tika-parsers/tika-parsers-standard/tika-parsers-standard-modules/tika-parser-image-module/src/test/java/org/apache/tika/parser/image/RawTiffParserTest.java
> Set Content-Length on embedded documents where the parser already knows it
> ---------------------------------------------------------------------------
>
> Key: TIKA-4873
> URL: https://issues.apache.org/jira/browse/TIKA-4873
> Project: Tika
> Issue Type: Improvement
> Reporter: Dominik Schmidt
> Priority: Major
>
> Several parsers emit embedded documents without a size. A client gets the
> type,
> the name and the resource path, but has to read the bytes to learn how many
> there are. Examples: the raw camera previews from RawTiffParser, the audio
> cover
> art from CoverArt, and the motion photo video from TIKA-4869 until it was
> added
> there.
> The convention is established elsewhere: ZipParser sets Content-Length from
> the
> zip entry (along with Zip:UncompressedSize), AbstractPOIFSExtractor from the
> OLE2 directory entry, AbstractPDF2XHTML from the embedded file specification,
> and RTF, PST and WARC do the same. In each of these the parser has the size in
> hand before it hands the stream over, and in the cases listed above it does
> too:
> the JPEG preview length comes from the IFD, the cover art length from the ID3
> or
> MP4 frame.
> Content-Length is not only an output. TikaInputStream.get(opener, tmp,
> metadata)
> takes the stream's length from it, so setting it before the embedded parse
> means
> that parse knows the length without spooling to measure it: MP4Parser, for
> one,
> bounds its box allocation with tis.hasLength() ? tis.getLength() : -1.
> TIKA-4106 approaches the same gap from the other end, by having the digester
> fill the length in. That covers callers who want digests, and only once the
> stream has been read; it does not help a caller who only wants to know how big
> an attachment is.
> Two steps, either of them useful on its own:
> 1. Set it in the parsers that already know the size, starting with
> RawTiffParser
> and CoverArt.
> 2. In ParsingEmbeddedDocumentExtractor.parseEmbedded, fill Content-Length when
> it is blank and tis.hasLength() is true. That costs nothing, never spools,
> and covers every embedded stream that is file or byte array backed,
> whatever
> parser produced it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
