[
https://issues.apache.org/jira/browse/TIKA-3372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17333027#comment-17333027
]
Julien Massiera edited comment on TIKA-3372 at 4/27/21, 8:09 AM:
-----------------------------------------------------------------
[~tallison] here is my use case :
I send a simple txt file containing 1 sentence to the /rmeta/txt endpoint of
the 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 is 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
was (Author: julienfl):
[~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)
