Rajmund Takacs created NIFI-15625:
-------------------------------------
Summary: 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
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)