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.
    
    



---
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 infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Reply via email to