[ https://issues.apache.org/jira/browse/NIFI-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15715969#comment-15715969 ]
ASF GitHub Bot commented on NIFI-3140: -------------------------------------- Github user JPercivall commented on the issue: https://github.com/apache/nifi/pull/1288 +1 Visually verified code and did a contrib-check build. In a standalone instance I ran FetchElasticsearchHTTP with and without a "type" hitting a secure 2.3 ES instance. Also used EL for the URL to verify NIFI-3095. Everything worked as expected. Thanks @mattyb149 I will merge it in. > 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)