[ https://issues.apache.org/jira/browse/NIFI-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15713752#comment-15713752 ]
ASF GitHub Bot commented on NIFI-3140: -------------------------------------- Github user mattyb149 commented on the issue: https://github.com/apache/nifi/pull/1288 @gresockj Do you mind taking a look at this? I want to make sure I didn't miss something in the API or any potential differences between versions. For the Http processors I'd like to keep the least-common-denominator principle, since they are the alternative to the other Transport-based processors that require a particular (major) version. Thanks! > FetchElasticsearchHttp no longer accepts optional type > ------------------------------------------------------ > > Key: NIFI-3140 > URL: https://issues.apache.org/jira/browse/NIFI-3140 > Project: Apache NiFi > Issue Type: Bug > Affects Versions: 1.1.0 > Reporter: Matt Burgess > Assignee: Matt Burgess > Fix For: 1.2.0 > > > In NiFi 1.1.0, if the Type property is omitted from the > FetchElasticsearchHttp configuration (and a specific index is specified > rather than _all), the processor fails with an error "400 Bad Request". > This is a result of FetchElasticsearchHttp URL building being aligned with > those used in the Query/ScrollElasticsearchHttp processors (added in > NIFI-2417). Unfortunately the REST API is not consistent between the Get and > Search APIs. > For FetchElasticsearchHttp, the logic should be restored to insert a path > segment of "_all" if the Type is not provided, and the Index property > description should be reverted to not imply the use of "_all". Although it is > possible to issue a successful Get against all indexes, it cannot have a type > or document ID specified, and even then it does not return a document but > instead a listing of indexes, which is inconsistent with the purpose of the > processor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)