[
https://issues.apache.org/jira/browse/NIFI-1620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15333040#comment-15333040
]
Adam Taft commented on NIFI-1620:
---------------------------------
So beyond the couple of nit-picky comments I made on the pull request in
Github, I think I'm still curious if it's better to support this functionality
*without* the proposed "send-message-body" property.
I'm wondering if a simpler approach is to suppress the Content-Type header for
all flowfiles of size zero. Otherwise, you're back in this edge case if you
attempt to transmit an empty flowfile and the user hasn't configured
'send-message-body = true' in their flow configuration. It might be more
consistent just to never transmit Content-Type for any zero sized flowfile,
without introducing a new property.
If the dataflow manager wants to always remove the payload before calling
InvokeHTTP, I think this could be accomplished with ReplaceText (or similar).
For the rare case that you want to use InvokeHTTP without transmitting the
flowfile content in the http message body, simply removing the content would be
very easily configured one processor above.
Possibly this PR should be postponed for 0.7.x and instead considered after
additional discussion. The key point is whether it makes sense to introduce a
new processor property for an arguably edge case.
> Allow empty Content-Type in InvokeHTTP processor
> ------------------------------------------------
>
> Key: NIFI-1620
> URL: https://issues.apache.org/jira/browse/NIFI-1620
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
> Affects Versions: 0.5.1
> Reporter: Pierre Villard
> Assignee: Pierre Villard
> Fix For: 1.0.0, 0.7.0
>
>
> External API could expect a POST request without a Content-Type property or
> at least with this property empty:
> *Error example:*
> {quote}
> You provided a non-empty HTTP "Content-Type" header ("application/json").
> This API function requires that the header be missing or empty.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
