在发出HTTP DELETE请求时,请求URI应该完全标识要删除的资源。但是,是否允许添加额外的元数据作为请求实体主体的一部分?
当前回答
规范并没有明确禁止或阻止它,所以我倾向于说它是允许的。
微软也是这么看的(我能听到听众的嘀嘀声),他们在MSDN的文章中提到了ADO的DELETE方法。NET数据服务框架:
如果一个DELETE请求包含一个实体体,该实体体将被忽略[…]
此外,这里是RFC2616 (HTTP 1.1)在请求方面所说的:
只有当消息体出现时,entity-body才会出现(第7.2节) 消息体的存在通过包含内容长度或传输编码头来表示(第4.3节)。 当请求方法的规范不允许发送实体体时(第4.3节),就不能包含消息体。 仅在TRACE请求中明确禁止使用实体体,所有其他类型的请求都不受限制(第9节,特别是9.8节)
对于响应,这已被定义为:
是否包含消息体取决于请求方法和响应状态(第4.3节) 明确禁止在HEAD请求的响应中使用消息体(第9节和9.4节) 1xx(信息)、204(无内容)和304(未修改)响应中明确禁止消息体(第4.3节) 所有其他响应都包含消息体,尽管消息体可能为零长度(第4.3节)
更新
在RFC 9110(2022年6月)中,明确了GET、HEAD和DELETE上的请求体不可互操作的事实。
9.3.5删除
Although request message framing is independent of the method used, 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 because of its potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). 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.
其他回答
ElasticSearch似乎使用了这个: https://www.elastic.co/guide/en/elasticsearch/reference/5.x/search-request-scroll.html#_clear_scroll_api
也就是说妮蒂支持这个。
就像评论中提到的那样,情况可能不再是这样了
其他几个回答提到了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.
这种语言在之前的语言基础上得到了加强,也就是说,即使它是允许的,在使用它时也需要非常小心,因为(例如)一些用户可能在代理的背后,为了打击“请求走私”而从请求中剥离主体。
2014年更新的HTTP 1.1规范(RFC 7231)明确地允许在DELETE请求中使用实体:
DELETE请求消息中的有效负载没有定义的语义;在DELETE请求上发送有效负载主体可能会导致某些现有实现拒绝该请求。
这个没有定义。
DELETE请求消息中的有效负载没有定义的语义; 在DELETE请求上发送有效负载主体可能会导致一些现有的问题 实现来拒绝请求。 https://www.rfc-editor.org/rfc/rfc7231#page-29
有些版本的Tomcat和Jetty似乎会忽略存在的实体体。如果你想要收到它,那就麻烦了。
推荐文章
- 哪个HTTP状态代码表示“尚未准备好,稍后再试”?
- Django REST框架:向ModelSerializer添加额外字段
- 如何阻止恶意代码欺骗“Origin”报头来利用CORS?
- 为什么说“HTTP是无状态协议”?
- 我需要HTTP GET请求的内容类型报头吗?
- REST和RPC之间的Web服务差异
- 如何让Chrome允许混合内容?
- 正确的方式删除cookies服务器端
- REST DELETE真的是幂等的吗?
- 如何用node.js实现一个安全的REST API
- 如何在Node.js内进行远程REST调用?旋度吗?
- 了解Chrome网络日志“停滞”状态
- 用户代理字符串可以有多大?
- 什么是接受* HTTP报头q=0.5 ?
- HTTP状态码200(缓存)和状态码304之间有什么区别?