[ 
https://issues.apache.org/jira/browse/NIFI-5550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy LoPresto resolved NIFI-5550.
---------------------------------
       Resolution: Fixed
    Fix Version/s: 1.8.0

This issue was resolved by PR 3035 in NIFI-5628. 

> Cluster should handle replicating DELETE request with non-zero content length 
> header
> ------------------------------------------------------------------------------------
>
>                 Key: NIFI-5550
>                 URL: https://issues.apache.org/jira/browse/NIFI-5550
>             Project: Apache NiFi
>          Issue Type: Bug
>          Components: Core Framework
>    Affects Versions: 1.5.0, 1.6.0, 1.7.1
>            Reporter: Andy LoPresto
>            Assignee: Andy LoPresto
>            Priority: Critical
>              Labels: cluster, http, request_replication, security
>             Fix For: 1.8.0
>
>
> When sending a {{DELETE}} request to a node in the cluster, the cluster 
> coordinator attempts to replicate the request to all nodes in the cluster 
> before committing it (*two phase commit*). According to [RFC 
> 7231|https://tools.ietf.org/html/rfc7231#section-4.3.5], a {{DELETE}} request 
> *may* have a body, but the body has no defined purpose:
> {quote}
> A payload within a DELETE request message has no defined semantics; sending a 
> payload body on a DELETE request might cause some existing implementations to 
> reject the request.
> {quote}
> The cluster request replication does not expect a request body when a DELETE 
> request is received, so when it replicates the request to other nodes, it 
> does not include the body, if present. However, the {{Content-Length}} header 
> is forwarded in tact, and if this header contains a non-zero length, the 
> other nodes will wait to receive the expected body. This can cause request 
> time outs. 
> The solution is to intercept {{DELETE}} requests with a non-zero 
> {{Content-Length}} header and overwrite that value to {{0}}. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to