I'm active on Stack Overflow a lot, and one thing that occasionally pops up is: Can a GET or DELETE request have a request body?

My answer to this currently stands at a score of -1:https://stackoverflow.com/questions/299628/is-an-entity-body-allowed-for-an-http-delete-request/54735278#54735278

But I think it's correct.

This is the wording forDELETE:

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.

Some people interpret 'no defined semantics' as, "I can define the semantics myself". That interpretation is somewhat similar to how someone might look at aPOST request and argue: the HTTP standard doesn't really say what the effect of aPOST request is.

So English and well, semantics aside... My understanding is that the intent for those paragraphs is so that generic parsers are possible, and a generic parsers don't need to know specifics about the methods to figure out whether to parse the body or not.

However, a real world effect is that:

1. People misinterpret the paragraph and assign a new meaning.
2. Others outright reject requests with a body.
3. Some of those in groupRFC 7231: Structure "Considerations for New Header Fields" #2 are intermediaries and cause problems for groupMethod case sensitivity #1.

I think the specification could benefit from stronger wording. I think even a sentence like this would help:

Implementations SHOULD not add a payload to DELETE requests.

But I would argue that, given that this is creating some interop issues that this is even more preferable:

Implementations SHOULD reject DELETE requests with a payload.