Tighten language around DELETE request bodies

[reschke]

(split from #202)

[reschke]

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 (#202 (comment))

[evert]

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:

1. A PATCH request on a resource that represents multiple underlying entities, some of which ought to be removed.
2. A DELETE request (without a body) on a resource that exactly represents the full collection of resources that should be deleted.
3. 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)

[reschke]

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.

[mnot]

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.

[reschke]

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.

[mnot]

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.

[reschke]

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.

[reschke]

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

[royfielding]

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

[royfielding]

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.

[reschke]

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.

[royfielding]

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

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