You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Alonso Gonzalez (Jira)" <ji...@apache.org> on 2023/11/24 13:22:00 UTC
[jira] [Updated] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body
[ https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alonso Gonzalez updated CXF-8962:
---------------------------------
Description:
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 handle DELETE requests 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]
was:
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 om omit the "Content-Type" header via the property "set.content.type.for.empty.request".
The new implementation handle DELETE requests 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]
> 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 handle DELETE requests 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)