[ 
https://issues.apache.org/jira/browse/SOLR-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13564230#comment-13564230
 ] 

Karl Wright commented on SOLR-4358:
-----------------------------------

My point is independent of SolrCell.  If anything in Solr were to care about 
the filename in a multipart post, then if SolrJ is making the decision to use 
standard POST vs multipart, it should also take care to eliminate any resulting 
differences in the Solr environment.  If SolrJ gives the user control over the 
posting method, then I don't care if SolrJ tries to fix this or not.
                
> SolrJ, by preventing multi-part post, loses key information about file name 
> that Tika needs
> -------------------------------------------------------------------------------------------
>
>                 Key: SOLR-4358
>                 URL: https://issues.apache.org/jira/browse/SOLR-4358
>             Project: Solr
>          Issue Type: Bug
>          Components: clients - java
>    Affects Versions: 4.0
>            Reporter: Karl Wright
>
> SolrJ accepts a ContentStream, which has a name field.  Within 
> HttpSolrServer.java, if SolrJ makes the decision to use multipart posts, this 
> filename is transmitted as part of the form boundary information.  However, 
> if SolrJ chooses not to use multipart post, the filename information is lost.
> This information is used by SolrCell (Tika) to make decisions about content 
> extraction, so it is very important that it makes it into Solr in one way or 
> another.  Either SolrJ should set appropriate equivalent headers to send the 
> filename automatically, or it should force multipart posts when this 
> information is present.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to