[
https://issues.apache.org/jira/browse/TIKA-3372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17333027#comment-17333027
]
Julien Massiera commented on TIKA-3372:
---------------------------------------
[~tallison] here is my use case :
I send a simple txt file containing 1 sentence to the /rmeta/txt endpoint of
Tika Server with two different requests:
{code:java}
// Request 1
curl -T test.txt --header "maxEmbeddedResources: 0"
http://localhost:9998/rmeta/txt --output ./result.json{code}
Once the request done, the result.json is containing the content of the txt
file in the X-TIKA:content field
{code:java}
// Request 2
curl -T test.txt --header "writeLimit: 5" --header "maxEmbeddedResources: 0"
http://localhost:9998/rmeta/txt --output ./result.json
{code}
With this request, the result.json does not contain any X-TIKA:content field,
but it contains the X-TIKA:EXCEPTION fields saying that the limit has been
reached
But I realized that by increasing the writeLimit to '10' I get the first 2
chars of the txt file, prefixed by a lot of \n (This was also the case with the
1st request, although I don't have any empty line before the sentence in the
file). So I suppose that with the writeLimit set to 5, Tika only gets an empty
char from the parsing and this is the reason why there is no content in the
result.json
> 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)
