You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "ASF subversion and git services (Jira)" <ji...@apache.org> on 2026/02/19 15:06:00 UTC

[jira] [Commented] (NIFI-15625) Remove Transfer-Encoding too during request replication

    [ https://issues.apache.org/jira/browse/NIFI-15625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18059713#comment-18059713 ] 

ASF subversion and git services commented on NIFI-15625:
--------------------------------------------------------

Commit b4ab5b0d581e2eac33be7f3c0eb15bffc41ad287 in nifi's branch refs/heads/main from Rajmund Takács
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=b4ab5b0d581 ]

NIFI-15625 Remove Transfer-Encoding Header from Replicated Requests (#10919)

- Added Transfer-Encoding to disallowed headers for framework replicated requests according to RFC 9112 Section 6.1 and 6.2

Signed-off-by: David Handermann <ex...@apache.org>

> Remove Transfer-Encoding too during request replication
> -------------------------------------------------------
>
>                 Key: NIFI-15625
>                 URL: https://issues.apache.org/jira/browse/NIFI-15625
>             Project: Apache NiFi
>          Issue Type: Bug
>    Affects Versions: 2.8.0
>            Reporter: Rajmund Takacs
>            Assignee: Rajmund Takacs
>            Priority: Major
>          Time Spent: 1h
>  Remaining Estimate: 0h
>
> If a client sends the request with {{Transfer-Encoding: chunked}}, then this header was not removed when NiFi forwarded it to the rest of the cluster, but it added {{Content-Length: nnnn}} and encoded the actual replicated request according to {{Content-Length}} rule. The receiving NiFi instance therefore had to deal with a request with both headers present, and it rejected it.
> Even if it would accept such requests, it should have been interpreted according to {{Transfer-Encoding}} rule, and would have failed to find the chunk boundaries in that case, and would have failed to parse it.
> Ref: https://www.rfc-editor.org/rfc/rfc9112           
> h3. Important quotes:
> h4. 6.1. Transfer-Encoding  
> {quote}
> Early implementations of {{Transfer-Encoding}} would occasionally send both a chunked transfer coding for message framing and an estimated {{Content-Length}} header field for use by progress bars. This is why {{Transfer-Encoding}} is defined as overriding {{Content-Length}}, as opposed to them being mutually incompatible.
> ...
> A server MAY reject a request that contains both {{Content-Length}} and {{Transfer-Encoding}} or process such a request in accordance with the {{Transfer-Encoding}} alone.
> {quote}
> h4. 6.2. Content-Length
> {quote}
> A sender MUST NOT send a {{Content-Length}} header field in any message that contains a {{Transfer-Encoding}} header field.
> {quote}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)