ChrisSamo632 commented on PR #9606: URL: https://github.com/apache/nifi/pull/9606#issuecomment-2698694077
@exceptionfactory thanks for continuing to look at this. > I think the general implementation approach looks good, but if there isn't a strong case for a variety of custom HTTP request headers, it seems better to avoid introducing this level of complexity for now. The use of request headers for Elasticsearch interaction is somewhat limited, but becomes a bit more relevant if people are using Elasticsearch-like services and/or proxies that require/allow extra request headers in-between. You're right that the use of `Accept` headers in the tests does highlight the possibility of someone introducing a configuration that would break NiFi's interaction with Elasticsearch, but the same could be said for other combinations of properties across the Elasticearch components within NiFi. The main use case I was raising this for is to allow for per-request (i.e. FlowFile of data coming through an Elasticsearch processor) setting of some request headers, namely the run-as-user. But I then chose not to put that in the tests as it may cause issues/confusion if not paired with other required headers that such an authentication mechanism needs within Elasticsearch. There are Flows where one may wish to index data as different users, but wouldn't necessarily know those users upfront, nor wish to create an ElasticsearchClientService controller and matching *Elasticsearch processor combination for every user that will be used for data ingest. The main example of this kind of approach that I can think of would be if the NiFi Flow were fronted by a HandleHttpRequest/ListenHTTP processor that is acting as a RESTful API endpoint - a setup that I've wanted to create in the past, but have had to agree for an alternative workaround in the meantime (which can complicate RBAC/ABAC controls within Elasticsearch itself, rather than relying on per-user access configuration). A more generic version of this would be if NiFi were to enable the use of FlowFile attributes at the Controller level, e.g. a property is evaluated at runtime from FlowFile attributes as they are within Processors. That, of course, is a much bigger framework-level change and comes with its own set of difficulties for things like this around connection pooling, etc. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
