[
https://issues.apache.org/jira/browse/HTTPCLIENT-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18006697#comment-18006697
]
Arturo Bernal edited comment on HTTPCLIENT-2382 at 7/15/25 11:00 AM:
---------------------------------------------------------------------
HI [~anasquazbary]
IMO this doesn't look like t a bug in Apache HttpClient—it’s exactly what the
HTTP/1.1 spec tells you to do:
According to {*}[RFC 7230
3.3.2|[http://example.com|https://datatracker.ietf.org/doc/html/rfc7230#section-3.3.2]]{*},
framing (i.e. whether you send a body) is dictated by your method’s semantics.
It says you *SHOULD* send {{Content-Length}} only when the method “defines a
meaning for an enclosed payload body,” and you *SHOULD NOT* send it when the
method “does not anticipate such a body” .
Then *[RFC 7231
4.3.5|[http://example.com|https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.5]]*
makes DELETE’s payload rules explicit: “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{*}.”
BTW I strongly recommend migrate to the 5.x version.
was (Author: abernal):
HI [~anasquazbary]
IMO this doesn't look like t a bug in Apache HttpClient—it’s exactly what the
HTTP/1.1 spec tells you to do:
According to {*}[RFC 7230
3.3.2|[http://example.com|https://datatracker.ietf.org/doc/html/rfc7230#section-3.3.2]]{*},
framing (i.e. whether you send a body) is dictated by your method’s semantics.
It says you *SHOULD* send {{Content-Length}} only when the method “defines a
meaning for an enclosed payload body,” and you *SHOULD NOT* send it when the
method “does not anticipate such a body” .
Then *[RFC 7231
4.3.5|[http://example.com|https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.5]]*
makes DELETE’s payload rules explicit: “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{*}.”
> Apache HttpClient removes the `Content-Length` header from a DELETE request
> even when the request has a body and the header is explicitly set.
> ----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-2382
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2382
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
> Reporter: Anas Quazbary
> Priority: Trivial
> Fix For: 5.3.1
>
>
> _(Usage via http4k-client-apache 5.29.0.0 with Apache HttpClient 5.3.1)_
> When using Apache HttpClient (via http4k in Kotlin), I noticed that the
> {{Content-Length}} header is removed from DELETE requests, even when:
> * a body is explicitly set, and
> * the header is manually added to the request.
> As a result, the request is rejected or mishandled by the server expecting
> the header (e.g., visible via ngrok).
> *To Reproduce*
> Steps to reproduce the behavior:
> # Create a {{DELETE}} request with a JSON body and explicitly set the
> {{Content-Length}} header.
> # Send it using Apache HttpClient (via http4k).
> # Observe the outgoing request (e.g., via ngrok or a proxy).
> # {{Content-Length}} is missing.
> kotlin :
> {code:java}
> val request = Request(Method.DELETE, "https://xxx.ngrok.io";)
> .header("Content-Type", "application/json")
> .header("Content-Length", "16")
> .body("""{"some": "data"}""")val client = ApacheClient()
> val response = client(request) {code}
> *Expected behavior:*
> Either:
> Apache HttpClient should honor manually set Content-Length when a body is
> present,
> or automatically compute and include it when a body is given, even for DELETE
> requests.
> Thank you for your time and assistance. Please let me know if you need any
> additional information to help diagnose this issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
