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

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

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

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

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

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

最后是不禁止尸体的原因

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

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

ElasticSearch似乎使用了这个: https://www.elastic.co/guide/en/elasticsearch/reference/5.x/search-request-scroll.html#_clear_scroll_api

也就是说妮蒂支持这个。

就像评论中提到的那样，情况可能不再是这样了

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

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

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

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

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

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

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

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

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