- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Mon, 17 Feb 2020 10:44:25 -0800
- To: Cory Benfield <cory@lukasa.co.uk>
- Cc: Rob Sayre <sayrer@gmail.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
> On Feb 17, 2020, at 1:53 AM, Cory Benfield <cory@lukasa.co.uk> wrote: > > The semantic requirement missing is that DELETE bodies have no > spec-defined semantics. This is not that they can't have semantics, or > that they shouldn't have spec-defined semantics, only that no > specification has ever said what a body in a DELETE request means. FTR, this is a common misinterpretation, but that is not what it says and certainly not what it means. They have no semantics in the sense that a body cannot change the meaning of a received request. They are absolutely forbidden to have any impact whatsoever on the processing or interpretation of the request aside from the necessity to read and discard the bytes received in order to maintain the message framing. The only reason we didn't forbid sending a body is because that would lead to lazy implementations assuming no body would be sent. This has always been the case for HTTP and GET/HEAD/PUT/DELETE. They were defined that way so that the URL would identify the resource and intermediaries would not have to delve into the body to reinterpret the semantics defined by method and header fields. The other request methods are more like POST and the original SEARCH. OPTIONS was defined much later with the intent of maybe needing a body for more complex queries, but we didn't have the energy or need to actually define one. ....Roy
Received on Monday, 17 February 2020 18:44:49 UTC