我认为这个问题还没有一个好的答案，尽管已经有很多关于现有答案的很好的评论。我将把这些评论的要点升华为一个新的答案:

RFC7231中的这段话已经被引用了几次，这确实总结了它。

DELETE请求消息中的有效负载没有定义的语义; 在DELETE请求上发送有效负载主体可能会导致一些现有的问题 实现来拒绝请求。

我忽略了其他答案的含义。是的，允许在DELETE请求中包含一个主体，但这在语义上是没有意义的。这实际上意味着，发出带有请求体的DELETE请求在语义上等同于不包含请求体。

包含一个请求体不应该对请求有任何影响，所以包含它是没有意义的。

tl;dr:从技术上讲，一个带有请求体的DELETE请求是允许的，但是这样做是没有用的。

只是一个提示，如果你在你的DELETE请求中提供了一个主体，并且使用了谷歌云HTTPS负载均衡器，它将拒绝你的请求，错误为400。我的头撞到墙上，然后发现谷歌，不管出于什么原因，认为一个带有主体的DELETE请求是一个畸形的请求。

2014年更新的HTTP 1.1规范(RFC 7231)明确地允许在DELETE请求中使用实体:

DELETE请求消息中的有效负载没有定义的语义;在DELETE请求上发送有效负载主体可能会导致某些现有实现拒绝该请求。

其他几个回答提到了RFC 7231，它有效地说了DELETE请求可以有一个主体，但不推荐。

在2022年，RFC 7231被RFC 9110: HTTP语义所取代，它现在说:

[...] 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 [...]. 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. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain.

这种语言在之前的语言基础上得到了加强，也就是说，即使它是允许的，在使用它时也需要非常小心，因为(例如)一些用户可能在代理的背后，为了打击“请求走私”而从请求中剥离主体。

也许下面的GitHUb url会帮助你，得到答案。 实际上，应用服务器，如Tomcat, Weblogic拒绝HTTP。带请求有效负载的DELETE调用。所以记住这些东西，我已经在github中添加了例子，请看看

https://github.com/ashish720/spring-examples

Roy Fielding在HTTP邮件列表上澄清了HTTP邮件列表https://lists.w3.org/Archives/Public/ietf-http-wg/2020JanMar/0123.html并说:

GET/DELETE主体绝对禁止产生任何影响 对请求的处理或解释

这意味着主体不能修改服务器的行为。 然后他补充道:

除了 为了维护，必须读取和丢弃接收到的字节 信息框架。

最后是不禁止尸体的原因

我们不禁止派人去的唯一原因是 因为这将导致懒惰的实现，假设没有人会这样做 被发送。

因此，当客户端可以发送有效负载主体时，服务器应该丢弃它 和api不应该为这些请求的有效载荷体定义语义。