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:

A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing implementations to reject the request.

That doesn't imply that you can't define semantics for it though.

Example: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.0/html/version_3_rest_api_guide/sect-examples#DELETE_Request_Including_Body_with_cURL

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.

https://stackoverflow.com/questions/299628/is-an-entity-body-allowed-for-an-http-delete-request

Now I'm confused.

Currently we say:

A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing implementations to reject the request.

That doesn't imply that you can't define semantics for it though.

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.

An intermediary that discards a DELETE body clearly is broken, right?

Nope. It's only required to read and discard the body.

Says who?

For example,

https://www.ibm.com/support/pages/isam-webseal-responds-400-bad-request-http-delete-body-content

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).