Details
-
New Feature
-
Status: Resolved
-
Major
-
Resolution: Implemented
-
1.10.0
-
None
Description
Multiple users have expressed difficultly configuring the InvokeHTTP processor to send multipart/form-data content to remote APIs.
While it is possible using a combination of ReplaceText processor to build the content boundaries and a custom header via a dynamic property in InvokeHTTP, this is not an ideal experience.
Rather, this could be implemented by:
- a native boolean property on InvokeHTTP which selects "multipart/form-data" (default false)
- a multiple value property which has options application/x-www-form-urlencoded (default), multipart/form-data, and text/plain
- a new processor which handles incoming flowfiles and modifies the content and attributes to be prepared for this transmission – this could be implemented for a single piece of content per flowfile or using the Record mechanism
Notes:
- Implementing the properties directly on the InvokeHTTP processor eliminates the need for an additional processor to prepare the data and does not prevent continuing operation of the same flowfile downstream in a linear flow. However, it does change the current scenario where "flowfile content is exactly what is sent" because it would "invisibly" wrap the content in the boundary markers. This could be remediated with a custom content viewer or custom UI
References:
- https://stackoverflow.com/a/4526286/70465
- https://dev.to/sidthesloth92/understanding-html-form-encoding-url-encoded-and-multipart-forms-3lpa
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/POST
- https://tools.ietf.org/html/rfc2388
- https://community.cloudera.com/t5/Support-Questions/How-to-send-an-http-POST-multipart-form-data-request-with-a/td-p/240035
Attachments
Issue Links
- is fixed by
-
NIFI-7394 InvokeHTTP Processor multipart/form-data support
- Resolved