[jira] [Commented] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body

2024-03-04 Thread Freeman Yue Fang (Jira) 


[ 
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823393#comment-17823393
 ] 

Freeman Yue Fang commented on CXF-8962:
---

Sure [~reta], done!

Cheers
Freeman

> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty 
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.6.2, 4.0.3
>Reporter: Alonso Gonzalez
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.6.3, 4.0.4
>
>
> We call a DELETE endoint of a REST API, but the server rejects the call with 
> a client error, because CXF sends "Content-Type: text/xml" although the 
> content is empty (as suggested by RFC 9110).
>  
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}} 
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods 
> computes a "Content-Type" header if the verb is not in the list 
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although 
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a 
> client follows the RFC and sends a DELETE request with no content, CXF will 
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses 
> "text/xml" as fallback if no content type can be computed. 
> The old implementation {{URLConnectionHTTPConduit}} called a 
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method 
> allowed to omit the "Content-Type" header via the property 
> "set.content.type.for.empty.request".
>  
> The new implementation should handle DELETE requests with empty body 
> correctly or evaluate the existing property 
> "set.content.type.for.empty.request".
>  
> [1]
> {quote}Although request message framing is independent of the method used, 
> content received in a DELETE request has no generally defined semantics, 
> cannot alter the meaning or target of the request, and might lead some 
> implementations to reject the request and close the connection because of its 
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A 
> client SHOULD NOT generate content in a DELETE request unless it is made 
> directly to an origin server that has previously indicated, in or out of 
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]



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

[jira] [Commented] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body

2024-03-04 Thread Andriy Redko (Jira) 


[ 
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823387#comment-17823387
 ] 

Andriy Redko commented on CXF-8962:
---

[~freeman.fang]  May I ask you please to backport this fix from main to 3.6.x, 
I sadly won't have access to laptop till Friday. Thank you very much, really 
appreciate it.

> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty 
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 3.6.2, 4.0.3
>Reporter: Alonso Gonzalez
>Assignee: Andriy Redko
>Priority: Major
> Fix For: 3.6.3, 4.0.4
>
>
> We call a DELETE endoint of a REST API, but the server rejects the call with 
> a client error, because CXF sends "Content-Type: text/xml" although the 
> content is empty (as suggested by RFC 9110).
>  
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}} 
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods 
> computes a "Content-Type" header if the verb is not in the list 
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although 
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a 
> client follows the RFC and sends a DELETE request with no content, CXF will 
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses 
> "text/xml" as fallback if no content type can be computed. 
> The old implementation {{URLConnectionHTTPConduit}} called a 
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method 
> allowed to omit the "Content-Type" header via the property 
> "set.content.type.for.empty.request".
>  
> The new implementation should handle DELETE requests with empty body 
> correctly or evaluate the existing property 
> "set.content.type.for.empty.request".
>  
> [1]
> {quote}Although request message framing is independent of the method used, 
> content received in a DELETE request has no generally defined semantics, 
> cannot alter the meaning or target of the request, and might lead some 
> implementations to reject the request and close the connection because of its 
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A 
> client SHOULD NOT generate content in a DELETE request unless it is made 
> directly to an origin server that has previously indicated, in or out of 
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]



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

[jira] [Commented] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body

2024-02-11 Thread Andriy Redko (Jira) 


[ 
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816407#comment-17816407
 ] 

Andriy Redko commented on CXF-8962:
---

Thanks for the update [~amichai] 

> Thanks for the workaround! btw does anyone know in what version the 
> workaround broke? 

So it does not really broke, but 3.6.2+/ 4.0.1+switched to JDK-11 HttpClient 
based conduit by default (so this setting does not apply there). But you still 
have a choice to select the previous conduit (setting another property) so the 
things should continue working.

> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty 
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with 
> a client error, because CXF sends "Content-Type: text/xml" although the 
> content is empty (as suggested by RFC 9110).
>  
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}} 
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods 
> computes a "Content-Type" header if the verb is not in the list 
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although 
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a 
> client follows the RFC and sends a DELETE request with no content, CXF will 
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses 
> "text/xml" as fallback if no content type can be computed. 
> The old implementation {{URLConnectionHTTPConduit}} called a 
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method 
> allowed to omit the "Content-Type" header via the property 
> "set.content.type.for.empty.request".
>  
> The new implementation should handle DELETE requests with empty body 
> correctly or evaluate the existing property 
> "set.content.type.for.empty.request".
>  
> [1]
> {quote}Although request message framing is independent of the method used, 
> content received in a DELETE request has no generally defined semantics, 
> cannot alter the meaning or target of the request, and might lead some 
> implementations to reject the request and close the connection because of its 
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A 
> client SHOULD NOT generate content in a DELETE request unless it is made 
> directly to an origin server that has previously indicated, in or out of 
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]



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

[jira] [Commented] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body

2024-02-11 Thread Amichai Rothman (Jira) 


[ 
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816382#comment-17816382
 ] 

Amichai Rothman commented on CXF-8962:
--

Scrath that, it's working now, though I have no idea why it didn't the first 
few hours I was debugging through it, and now it does. Didn't change the code 
in between... maybe just something not updating right in debugger or something. 
Thanks for the workaround! btw does anyone know in what version the workaround 
broke? So we don't update to it by mistake...

> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty 
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with 
> a client error, because CXF sends "Content-Type: text/xml" although the 
> content is empty (as suggested by RFC 9110).
>  
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}} 
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods 
> computes a "Content-Type" header if the verb is not in the list 
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although 
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a 
> client follows the RFC and sends a DELETE request with no content, CXF will 
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses 
> "text/xml" as fallback if no content type can be computed. 
> The old implementation {{URLConnectionHTTPConduit}} called a 
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method 
> allowed to omit the "Content-Type" header via the property 
> "set.content.type.for.empty.request".
>  
> The new implementation should handle DELETE requests with empty body 
> correctly or evaluate the existing property 
> "set.content.type.for.empty.request".
>  
> [1]
> {quote}Although request message framing is independent of the method used, 
> content received in a DELETE request has no generally defined semantics, 
> cannot alter the meaning or target of the request, and might lead some 
> implementations to reject the request and close the connection because of its 
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A 
> client SHOULD NOT generate content in a DELETE request unless it is made 
> directly to an origin server that has previously indicated, in or out of 
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]



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

[jira] [Commented] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body

2024-02-11 Thread Amichai Rothman (Jira) 


[ 
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816378#comment-17816378
 ] 

Amichai Rothman commented on CXF-8962:
--

That doesn't work. I put a breakpoint there and see it set, then another 
breakpoint in Headers.setProtocolHeadersInConnection where it reads it with 
setCtForEmptyRequestProp = 
message.getContextualProperty(SET_EMPTY_REQUEST_CT_PROPERTY); but there the 
property is null.

> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty 
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with 
> a client error, because CXF sends "Content-Type: text/xml" although the 
> content is empty (as suggested by RFC 9110).
>  
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}} 
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods 
> computes a "Content-Type" header if the verb is not in the list 
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although 
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a 
> client follows the RFC and sends a DELETE request with no content, CXF will 
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses 
> "text/xml" as fallback if no content type can be computed. 
> The old implementation {{URLConnectionHTTPConduit}} called a 
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method 
> allowed to omit the "Content-Type" header via the property 
> "set.content.type.for.empty.request".
>  
> The new implementation should handle DELETE requests with empty body 
> correctly or evaluate the existing property 
> "set.content.type.for.empty.request".
>  
> [1]
> {quote}Although request message framing is independent of the method used, 
> content received in a DELETE request has no generally defined semantics, 
> cannot alter the meaning or target of the request, and might lead some 
> implementations to reject the request and close the connection because of its 
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A 
> client SHOULD NOT generate content in a DELETE request unless it is made 
> directly to an origin server that has previously indicated, in or out of 
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]



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

[jira] [Commented] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body

2024-02-10 Thread Andriy Redko (Jira) 


[ 
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816362#comment-17816362
 ] 

Andriy Redko commented on CXF-8962:
---

[~amichai] Hm ... you could do it like that:
{noformat}
WebClient.getConfig(client).getRequestContext().put("set.content.type.for.empty.request",
 true); {noformat}
{color:#00}which is actually equivalent to 
client.getConfiguration().getRequestContext().put(...) {color}
 

> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty 
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with 
> a client error, because CXF sends "Content-Type: text/xml" although the 
> content is empty (as suggested by RFC 9110).
>  
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}} 
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods 
> computes a "Content-Type" header if the verb is not in the list 
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although 
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a 
> client follows the RFC and sends a DELETE request with no content, CXF will 
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses 
> "text/xml" as fallback if no content type can be computed. 
> The old implementation {{URLConnectionHTTPConduit}} called a 
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method 
> allowed to omit the "Content-Type" header via the property 
> "set.content.type.for.empty.request".
>  
> The new implementation should handle DELETE requests with empty body 
> correctly or evaluate the existing property 
> "set.content.type.for.empty.request".
>  
> [1]
> {quote}Although request message framing is independent of the method used, 
> content received in a DELETE request has no generally defined semantics, 
> cannot alter the meaning or target of the request, and might lead some 
> implementations to reject the request and close the connection because of its 
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A 
> client SHOULD NOT generate content in a DELETE request unless it is made 
> directly to an origin server that has previously indicated, in or out of 
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]



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

[jira] [Commented] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body

2024-02-10 Thread Amichai Rothman (Jira) 


[ 
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17816318#comment-17816318
 ] 

Amichai Rothman commented on CXF-8962:
--

This is embarassing but I can't figure out where to set that property on the 
WebClient... client.getConfiguration().getBus().setProperty() didn't work, 
client.
getConfiguration().getRequestContext().put() didn't work, where are these 
properties supposed to come from?

> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty 
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with 
> a client error, because CXF sends "Content-Type: text/xml" although the 
> content is empty (as suggested by RFC 9110).
>  
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}} 
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods 
> computes a "Content-Type" header if the verb is not in the list 
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although 
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a 
> client follows the RFC and sends a DELETE request with no content, CXF will 
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses 
> "text/xml" as fallback if no content type can be computed. 
> The old implementation {{URLConnectionHTTPConduit}} called a 
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method 
> allowed to omit the "Content-Type" header via the property 
> "set.content.type.for.empty.request".
>  
> The new implementation should handle DELETE requests with empty body 
> correctly or evaluate the existing property 
> "set.content.type.for.empty.request".
>  
> [1]
> {quote}Although request message framing is independent of the method used, 
> content received in a DELETE request has no generally defined semantics, 
> cannot alter the meaning or target of the request, and might lead some 
> implementations to reject the request and close the connection because of its 
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A 
> client SHOULD NOT generate content in a DELETE request unless it is made 
> directly to an origin server that has previously indicated, in or out of 
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]



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

[jira] [Commented] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body

2024-02-08 Thread Guillaume Chauvet (Jira) 


[ 
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815956#comment-17815956
 ] 

Guillaume Chauvet commented on CXF-8962:


hello [~reta] ,

Works for me with 3.5.7 and 3.3.13. However, we're going to put our version 
3.1.x problem on hold, as our supplier will be updating its technical stack in 
the next update (we are stuck by this).

 

Thanks for everything,

Regards

> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty 
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with 
> a client error, because CXF sends "Content-Type: text/xml" although the 
> content is empty (as suggested by RFC 9110).
>  
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}} 
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods 
> computes a "Content-Type" header if the verb is not in the list 
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although 
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a 
> client follows the RFC and sends a DELETE request with no content, CXF will 
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses 
> "text/xml" as fallback if no content type can be computed. 
> The old implementation {{URLConnectionHTTPConduit}} called a 
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method 
> allowed to omit the "Content-Type" header via the property 
> "set.content.type.for.empty.request".
>  
> The new implementation should handle DELETE requests with empty body 
> correctly or evaluate the existing property 
> "set.content.type.for.empty.request".
>  
> [1]
> {quote}Although request message framing is independent of the method used, 
> content received in a DELETE request has no generally defined semantics, 
> cannot alter the meaning or target of the request, and might lead some 
> implementations to reject the request and close the connection because of its 
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A 
> client SHOULD NOT generate content in a DELETE request unless it is made 
> directly to an origin server that has previously indicated, in or out of 
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]



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

[jira] [Commented] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body

2024-02-08 Thread Andriy Redko (Jira) 


[ 
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815872#comment-17815872
 ] 

Andriy Redko commented on CXF-8962:
---

[~amichai] you could set 
{color:#00}{color:#2a00ff}set.content.type.for.empty.request{color}{color} 
context property to skip Content-Type header for empty request (for 3.5.x 
release branch).

> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty 
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with 
> a client error, because CXF sends "Content-Type: text/xml" although the 
> content is empty (as suggested by RFC 9110).
>  
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}} 
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods 
> computes a "Content-Type" header if the verb is not in the list 
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although 
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a 
> client follows the RFC and sends a DELETE request with no content, CXF will 
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses 
> "text/xml" as fallback if no content type can be computed. 
> The old implementation {{URLConnectionHTTPConduit}} called a 
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method 
> allowed to omit the "Content-Type" header via the property 
> "set.content.type.for.empty.request".
>  
> The new implementation should handle DELETE requests with empty body 
> correctly or evaluate the existing property 
> "set.content.type.for.empty.request".
>  
> [1]
> {quote}Although request message framing is independent of the method used, 
> content received in a DELETE request has no generally defined semantics, 
> cannot alter the meaning or target of the request, and might lead some 
> implementations to reject the request and close the connection because of its 
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A 
> client SHOULD NOT generate content in a DELETE request unless it is made 
> directly to an origin server that has previously indicated, in or out of 
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]



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

[jira] [Commented] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body

2024-02-08 Thread Amichai Rothman (Jira) 


[ 
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815784#comment-17815784
 ] 

Amichai Rothman commented on CXF-8962:
--

We're also seeing rejected DELETE requests due to this issue :(

Is there a known workaround?

> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty 
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with 
> a client error, because CXF sends "Content-Type: text/xml" although the 
> content is empty (as suggested by RFC 9110).
>  
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}} 
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods 
> computes a "Content-Type" header if the verb is not in the list 
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although 
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a 
> client follows the RFC and sends a DELETE request with no content, CXF will 
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses 
> "text/xml" as fallback if no content type can be computed. 
> The old implementation {{URLConnectionHTTPConduit}} called a 
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method 
> allowed to omit the "Content-Type" header via the property 
> "set.content.type.for.empty.request".
>  
> The new implementation should handle DELETE requests with empty body 
> correctly or evaluate the existing property 
> "set.content.type.for.empty.request".
>  
> [1]
> {quote}Although request message framing is independent of the method used, 
> content received in a DELETE request has no generally defined semantics, 
> cannot alter the meaning or target of the request, and might lead some 
> implementations to reject the request and close the connection because of its 
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A 
> client SHOULD NOT generate content in a DELETE request unless it is made 
> directly to an origin server that has previously indicated, in or out of 
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]



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

[jira] [Commented] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body

2024-02-02 Thread Guillaume Chauvet (Jira) 


[ 
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17813667#comment-17813667
 ] 

Guillaume Chauvet commented on CXF-8962:


Same issue on versions 3.1.4 to 3.5.7:

 
{noformat}
Address: https://
Http-Method: DELETE
Content-Type:
Headers: {Accept=[text/plain] }
{noformat}
 

 

> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty 
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
>  Issue Type: Bug
>  Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with 
> a client error, because CXF sends "Content-Type: text/xml" although the 
> content is empty (as suggested by RFC 9110).
>  
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}} 
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods 
> computes a "Content-Type" header if the verb is not in the list 
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although 
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a 
> client follows the RFC and sends a DELETE request with no content, CXF will 
> nonetheless set a Content-Type header. {{Headers#determineContentType}} uses 
> "text/xml" as fallback if no content type can be computed. 
> The old implementation {{URLConnectionHTTPConduit}} called a 
> {{Headers#setProtocolHeadersInConnection}} to set the headers. This method 
> allowed to omit the "Content-Type" header via the property 
> "set.content.type.for.empty.request".
>  
> The new implementation should handle DELETE requests with empty body 
> correctly or evaluate the existing property 
> "set.content.type.for.empty.request".
>  
> [1]
> {quote}Although request message framing is independent of the method used, 
> content received in a DELETE request has no generally defined semantics, 
> cannot alter the meaning or target of the request, and might lead some 
> implementations to reject the request and close the connection because of its 
> potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A 
> client SHOULD NOT generate content in a DELETE request unless it is made 
> directly to an origin server that has previously indicated, in or out of 
> band, that such a request has a purpose and will be adequately supported.
> {quote}
> [https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]



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