[
https://issues.apache.org/jira/browse/TIKA-3372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17334844#comment-17334844
]
Tim Allison commented on TIKA-3372:
-----------------------------------
As for your above point, there's often a bunch of \n at the beginning of the
text handler because of the translation of the sax events to the text handler.
So, y, that's expected, unfortunately. Whitespace counts towards the
writelimit, but sax entities don't.
All that said, there was clearly a bug that is now fixed in the 1.x branch. If
you can grab a nightly build and test it out before we release 1.27, that'd be
great. Thank you.
> Fix writelimit in recursiveparserhandler
> ----------------------------------------
>
> Key: TIKA-3372
> URL: https://issues.apache.org/jira/browse/TIKA-3372
> Project: Tika
> Issue Type: Task
> Reporter: Tim Allison
> Priority: Major
>
> On the dev list, [~julienFL] noted surprising behavior with the new write
> limit in the /rmeta handler. I wasn't able to replicate it, but there is
> clearly a bug in how the write limiting is working. The upshot is that we're
> still effectively write limiting per object not for the full container doc
> and embedded objects.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
