Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DELETE request without body uses transfer-encoding: chunked #3548

Closed
AndreasKasparek opened this issue Dec 17, 2024 · 1 comment · Fixed by #3549
Closed

DELETE request without body uses transfer-encoding: chunked #3548

AndreasKasparek opened this issue Dec 17, 2024 · 1 comment · Fixed by #3549
Assignees
Labels
type/bug A general bug warn/regression A regression from a previous release
Milestone

Comments

@AndreasKasparek
Copy link

With #3481 (in v 1.1.24 and 1.2.0) the handling of DELETE requests in HttpClientHandler was changed. As mentioned by @bachah in #3481 (comment), the handler now always sets the HTTP request header transfer-encoding: chunked even if there is no payload (empty body). In previous versions that was not the case.

We are using SpringCloudGateway to route requests to a Payara web server. When upgrading the SpringBoot version of our gateway from 3.3.5 to 3.3.6, this pulled in reactor-netty-http v1.2.0 which added the changed behavior. Payara seems to treat incoming requests with transfer-encoding: chunked as having a body, and it forbids DELETE requests from sending a payload and therefore responds with status 400 Bad Request.

The Netty change broke our setup. We had to change the configuration of our Payara server as described here to allow potential payloads for DELETE requests (even so in our use cases we never send a body).

We are fine now, but I guess this change may also affect others. Can the transfer-encoding header be omitted by default if a DELETE request does not contain a body?

@AndreasKasparek AndreasKasparek added status/need-triage A new issue that still need to be evaluated as a whole type/bug A general bug labels Dec 17, 2024
@violetagg violetagg added this to the 1.1.26 milestone Dec 17, 2024
@violetagg violetagg removed the status/need-triage A new issue that still need to be evaluated as a whole label Dec 17, 2024
@violetagg violetagg self-assigned this Dec 17, 2024
@violetagg violetagg added the warn/regression A regression from a previous release label Dec 17, 2024
violetagg added a commit that referenced this issue Dec 17, 2024
@violetagg violetagg linked a pull request Dec 17, 2024 that will close this issue
@violetagg
Copy link
Member

@AndreasKasparek Thanks for the report. The fix will be available with the next release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/bug A general bug warn/regression A regression from a previous release
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants