Github user pipern commented on the issue:
https://github.com/apache/nifi/pull/1795
Thanks for taking a look @joewitt .
The old behaviour is persisted if _Multipart part name pattern_ property is
not set (and not set is the default.)
The current implementation in this PR does only grab the first matching
Part. It's an obvious next step to grab all matching parts, and indeed, maybe
it's better to wait and improve this before merging, so that the behaviour
doesn't change later. The implementation in the PR meets our own need, so
unsure if we'll get chance to revisit and make the improvement soon.
I can also imagine an implementation which puts some parts into content,
and some parts into attributes. Maybe a step towards that is, building on the
current PR, to:
* Rename _Multipart part name pattern_ as _Multipart file part name
pattern_ (and then generate several flowfiles, one for each matching part)
* Add _Multipart attribute part name pattern_ (and then, for each otherwise
generated flowfile, put these parts as attributes)
> ExtractMultiPartHttp for example could take as input the entire request
body in a flowfile that came from ListenHTTP and this new processor could
create child objects which are each of the parts.
This would also need the ContentType header to be kept by the ListenHTTP
(which it can do.)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
