[
https://issues.apache.org/jira/browse/NIFI-1620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15192561#comment-15192561
]
ASF GitHub Bot commented on NIFI-1620:
--------------------------------------
Github user taftster commented on the pull request:
https://github.com/apache/nifi/pull/272#issuecomment-196079414
I'm not entirely sure if this is a good idea. Any web service which
_disallows_ a standard HTTP header is arguably broken. Quoting RFC 2616:
> Any HTTP/1.1 message containing an entity-body SHOULD include a
> Content-Type header field defining the media type of that body. If
> and only if the media type is not given by a Content-Type field, the
> recipient MAY attempt to guess the media type via inspection of its
> content and/or the name extension(s) of the URI used to identify the
> resource. If the media type remains unknown, the recipient SHOULD
> treat it as type "application/octet-stream".
It seems hard to believe given the above that a web service would reject a
response with Content-Type. The current behavior of InvokeHTTP is possibly the
most consistent with the HTTP specification.
A custom processor designed to specifically interact with the remote
service in question should be considered as an alternative to modifying
InvokeHTTP.
> 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: 0.6.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)
