实体主体是否允许HTTP DELETE请求？

发出HTTP DELETE请求时,请求URI应完全标识要删除的资源.但是,是否允许添加额外的元数据作为请求的实体主体的一部分？

1> Tomalak..：

---

该规范没有明确禁止或阻止它,所以我倾向于说它是允许的.

微软以同样的方式看待它(我可以听到观众中的嘀咕声),他们在MSDN文章中指出ADO.NET数据服务框架的DELETE方法:

如果DELETE请求包含实体主体,则忽略正文[...]

另外这里是RFC2616(HTTP 1.1)对请求的说法:

一个实体主体是仅当存在时一个消息体存在(第7.2部分)

通过包含a 或标题来表示消息体的存在(第4.3节)Content-LengthTransfer-Encoding

一个消息体必须不被包括在所述请求的方法的规范不允许发送实体主体(第4.3节)

一个实体主体仅在TRACE请求明确禁止,所有其它请求类型是不受限制的(第9节和9.8特异性)

对于回复,这已经定义:

是否包含消息正文取决于请求方法和响应状态(第4.3节)

一个消息体在以HEAD请求的响应明确禁止(第9节,和9.4特异性)

一个消息体被明确禁止在1XX(信息),204(无内容),和304(未修饰的)反应(第4.3节)

所有其他响应都包含一个消息体,尽管它可能是零长度(第4.3节)

---

尽管规范并未禁止DELETE请求拥有消息体,[第4.3节](http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.3)似乎表明_身体应该被servers_忽略,因为[DELETE](http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.7)实体主体没有"定义的语义":"服务器应该是什么在任何请求上读取和转发消息体;**如果请求方法不包含实体体的定义语义,则在处理请求时应该忽略消息体**.

---

请注意,许多客户也无法发送带有正文的DELETE.这只是在Android上烧毁了我.

---

@Jason绝对.您还可以使用自定义标头传递其他数据,但为什么不使用请求正文.

2> grzes..：

---

HTTP 1.1规范(RFC 7231)的最新更新明确允许DELETE请求中的实体主体:

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

---

版本26建议您可以允许正文:`DELETE请求消息中的有效负载没有定义的语义; 在DELETE请求上发送一个有效负载体可能会导致一些现有的实现拒绝该请求.因此它带有一个向后兼容性警告,它暗示下一个标准将会说:'是的!`DELETE`可以有一个身体`.

---

[RFC 7231第4.3.5节](https://tools.ietf.org/html/rfc7231#section-4.3.5)使用"DELETE请求消息中的有效负载没有定义的语义"来完成第26版的语言.所以身体是允许的.

---

最新未经批准的规范版本删除了此要求.最新批准的版本仍然是上面引用的RFC2616.

---

哪个版本？版本20仍然具有与上面链接的版本19相同的措辞:"DELETE请求上的实体没有定义的语义.请注意,在DELETE请求上发送正文可能会导致某些现有实现拒绝请求."

---

正文是允许的，但与请求无关。使用它绝对没有意义。

3> evan.leonard..：

---

某些版本的Tomcat和Jetty似乎忽略了实体主体(如果存在).如果您打算收到它可能会令人讨厌.

---

我和Tomcat v6u39一起工作过.

---

适用于Tomcat 7

---

和Tomcat 8.0.12

4> Neil McGuiga..：

---

在删除请求中使用正文的一个原因是乐观并发控制.

您阅读了记录的第1版.

GET /some-resource/1
200 OK { id:1, status:"unimportant", version:1 }

您的同事阅读记录的第1版.

GET /some-resource/1
200 OK { id:1, status:"unimportant", version:1 }

您的同事更改记录并更新数据库,将版本更新为2:

PUT /some-resource/1 { id:1, status:"important", version:1 }
200 OK { id:1, status:"important", version:2 }

您尝试删除记录:

DELETE /some-resource/1 { id:1, version:1 }
409 Conflict

您应该获得乐观的锁定异常.重新阅读记录,看它是重要的,也许不能删除它.

使用它的另一个原因是一次删除多个记录(例如,带有行选择复选框的网格).

DELETE /messages
[{id:1, version:2},
{id:99, version:3}]
204 No Content

请注意,每条消息都有自己的版本.也许你可以使用多个标题来指定多个版本,但是通过George,这更简单,更方便.

这适用于Tomcat(7.0.52)和Spring MVC(4.05),也可能是早期版本:

@RestController
public class TestController {

    @RequestMapping(value="/echo-delete", method = RequestMethod.DELETE)
    SomeBean echoDelete(@RequestBody SomeBean someBean) {
        return someBean;
    }
}

---

当规范不禁止DELETE中的身体时,它是如何明确地误解它的？

---

在GET(和DELETE)中拥有主体显然是在虐待HTTP和REST.还有其他处理并发控制的机制(例如If-Modified-Since和etags).

---

这是完全相同的问题:GET允许您检索由URI标识的资源的表示,DELETE删除由URI标识的资源.如果要删除特定版本,请为其他版本使用不同的URI.URI应该是HTTP/REST中资源的唯一标识符.如果你需要处理并发性,请在头文件中使用元数据(例如`If-Unmodified-Since`或`Etag`,这就是他们的用途).

---

因为你不打算对身体做任何事情.请参阅:http://stackoverflow.com/a/983458/372643

---

使用ETag标头代替正文中的版本字段

---

很抱歉在一年之后很难记住这个讨论.不,不一定(这里的主要问题是建议在DELETE中使用正文).URI是标识符,由您来选择它们识别的内容,更重要的是,您的意思*.例如,[这个答案](http://stackoverflow.com/a/18141127/372643)有一个URI(实际上是多个,具体取决于谁分享它),但每个版本都有自己的URI [1]( http://stackoverflow.com/revisions/18141127/1)和[2](http://stackoverflow.com/revisions/18141127/2).这一切都取决于你用标识符识别的意思.

---

我会使用标头传递版本，而不是正文。

---

显式地将`DELETE`与语义请求主体一起使用意味着您将抛弃HTTP，并定义自己的变体。您是否更喜欢对请求正文使用GET或DELETE是无关紧要的。一致的HTTP工具将删除或忽略主体。

5> Adam Rosenfi..：

---

在我看来,RFC 2616没有指定这一点.

从第4.3节:

通过在请求的消息头中包含Content-Length或Transfer-Encoding头字段来指示请求中消息体的存在.如果请求方法的规范(第5.1.1节)不允许在请求中发送实体主体,则消息主体不得包含在请求中.服务器应该在任何请求上读取和转发消息体; 如果请求方法不包含实体主体的定义语义,那么在处理请求时应该忽略消息主体.

第9.7节:

DELETE方法请求源服务器删除Request-URI标识的资源.可以通过源服务器上的人为干预(或其他方式)覆盖此方法.即使从源服务器返回的状态代码表明操作已成功完成,也无法保证客户端已执行该操作.但是,服务器不应该指示成功,除非在给出响应时,它打算删除资源或将其移动到不可访问的位置.

如果响应包括描述状态的实体,则成功响应应为200(OK),如果操作尚未执行,则应为202(已接受);如果操作已颁布但响应不包括,则应为204(无内容)一个实体.

如果请求通过缓存并且Request-URI标识了一个或多个当前缓存的实体,那么这些条目应该被视为陈旧.对此方法的响应不是cacheable.c

所以它没有被明确允许或禁止,并且沿途的代理可能会删除消息体(尽管它应该读取并转发它).

6> Ben Fried..：

---

只是抬头,如果您在DELETE请求中提供正文并使用Google云端HTTPS负载均衡器,它将拒绝您的请求,并出现400错误.我正撞在墙上,发现Google出于某种原因认为带有正文的DELETE请求是一个格式错误的请求.

---

规范并没有"说出来"它只是说身体没有特别定义.如果它没有被定义,并且你想忽略它,那么很酷......继续并忽略它.但是完全拒绝这个要求似乎极端而且没必要.

7> Clever Human..：

---

值得注意的是,版本3.0的OpenAPI规范放弃了对具有正文的DELETE方法的支持:

看这里和这里的参考

这可能会影响您将来实施,记录或使用这些API.

8> Sebastien Lo..：

---

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

这意味着Netty支持这一点.

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

---

链接的文档现在只包含POST请求,没有DELETE.可能值得为这个答案添加注释吗？

---

死链接 - 很棒.我们需要更多这些链接答案 - 不是

9> 小智..：

---

这没有定义.

DELETE请求消息中的有效负载没有定义的语义; 在DELETE请求上发送有效负载主体可能会导致某些现有实现拒绝该请求.
https://tools.ietf.org/html/rfc7231#page-29

---

之前的答案中已经包含此确切的报价，应删除此答案。