[
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
