Original text:
If a DELETE method is successfully applied, the origin server SHOULD send <del> A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing </del>  implementations to reject the request. Responses to the DELETE method are not cacheable.  If a successful

Reviewer comments:
:-(
(split from URL)
So the main question seems to be: is the situation for DELETE the same as for GET, or maybe more similar to OPTIONS. As far as I remember, the latter is what we discussed in Prague 2019 (URL)
I might be wrong, but I believe the intent of the DELETE method is to just delete the target resource. Most of the cases out there that use a request body in the DELETE method, is to use 'delete' as a sort of rpc call to delete other, unrelated resources. While I think that this use-case is valid, I think that it would be better solved with: A PATCH request on a resource that represents multiple underlying entities, some of which ought to be removed. A DELETE request (without a body) on a resource that exactly represents the full collection of resources that should be deleted. A POST request with some custom media-type with delete instructions. Given that DELETE (unlike OPTIONS) is a non-safe method, and conforming services are likely to ignore request bodies and simply delete the context resource, I believe that DELETE should get the same treatment as GET: Emphasize that the request body has no semantic meaning. Improve the prose so there's less chance of misinterpretation (like GET)
I agree that using the payload to instruct the server to delete something other than the identified resource is incorrect, and we could mention that. There are uses cases though where the payload would add additional information about the deletion (keep version history? move to waste basket? archive?). In all these cases, this would be consistent with the overall semantics.
That's very theoretical. I suspect DELETE is very much in the same bucket as GET -- i.e., many intermediaries, servers, etc. will block a DELETE request with a body.
I disagree that it's theoretical. This would be a normative change from RFC 723x, so if you think that handling of DELETE is more like GET (than for instance OPTIONS), please prove it.
The onus isn't on me to prove that we can use DELETE in a way that isn't currently countenanced by the specs; if you want to open it up, do the work.
Now I'm confused. Currently we say: That doesn't imply that you can't define semantics for it though.
Example: URL
We can sit here forever and point out individual examples where developers are trying to use a body with DELETE. That's hopeless, particularly for examples like that redhat one where they are providing control data that needs to be in the header fields. In any case, sending a body with DELETE is not interoperable. Compliant servers will read and ignore them. Non-compliant servers will treat the body as the next request, resulting in request smuggling. URL
Yes, that is exactly what it implies. If you send a body, the recipient cannot use that body to have any meaningful impact on the request semantics.
Doesn't compute for me. An intermediary that discards a DELETE body clearly is broken, right? For an origin server to support certain payloads in DELETE requests has always been ok. If the user agents knows who he's talking to, why not allow him to send the payload? Where is the harm? All I would add would be a warning that even if you provide additional information to the DELETE request, it still needs to be aligned with the base semantics.
Nope. It's only required to read and discard the body.
Says who?
For example, URL
I know we get a lot of grief from those sentences about "has no defined semantics", but I am quite certain that they are trying to forbid using a body while at the same time avoiding message parsers that are dependent on the request semantics. HEAD was a disaster and I was trying to prevent any further damage.
IMHO: at the end of the day, this ticket is about making a normative change that will break some existing use cases, so it would need a better reason than "it might not work". But let's do a proper analysis first. You said that an intermediate MUST read the payload, but MAY drop it (right?). What part of the spec supports this? And is this specific to DELETE, or does it also apply to "PATCH" or "FOO"?
Discussed in Singapore; room sense was to behave like GET (body not allowed).

Revised text:
If a DELETE method is successfully applied, the origin server SHOULD send  <ins> A client SHOULD NOT generate a body in a DELETE request.  A payload received in a DELETE request has no defined semantics, cannot alter the meaning or target of the request, and might lead some </ins> implementations to reject the request. Responses to the DELETE method are not cacheable.  If a successful