Tighten language around GET request bodies

[evert]

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 for DELETE:

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 a POST request and argue: the HTTP standard doesn't really say what the effect of a POST 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 group RFC 7231: Structure "Considerations for New Header Fields" #2 are intermediaries and cause problems for group Method 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.

[mnot]

Discussed amongst editors;

• GET can be strengthened with "... sender SHOULD NOT generate..." language. We may want to reinforce that this is not coupled with parsing in semantics or messaging
• DELETE should have a conversation about what the use cases are and whether this is recommended and what current implementations do with it. If we decide to allow it, it'll probably look something like the language around OPTIONS.

[mcmanus]

ietf104: general agreement on SHOULDing against GET bodies

e2e arguments cited wrt treating DELETE with the same level of guidance. Julian argues it is more like OPTIONS which could have a body depending on media type.

[evert]

One big difference with OPTIONS is that it's a safe method, so even if a body is ignored it doesn't have side-effects, unless a request body with an Expect header is used.

[yxhuvud]

Regarding DELETE, current use cases can be found in the json:api ( documentation.https://jsonapi.org/format/#crud-updating-to-many-relationships )

(see also OAI/OpenAPI-Specification#1801 for more discussion)

[reschke]

@yxhuvud - I believe the example use of DELETE with body in json:api is very misguided. It uses the payload to identify the actual resources to be deleted, while the resource identified by the request URI is not deleted.

[reschke]

Given the example from json:api, maybe we need to explain that sendig a payload body can not modify the base semantics of the request: deleting the resource identified by the request URI. Or is this a separate issue?

[royfielding]

If you mean like
A payload within a GET request message has no defined semantics and cannot be used to alter those semantics.

+1 to that.

I also see no reason to change specification of DELETE, other than to be consistent with GET.

[reschke]

@royfielding: consistency is good, but DELETE is very different from GET. If we change something here, it should lead to consistency with OPTIONS. My proposal is to restrict this change to GET, and consider DELETE separately.

[reschke]

I have opened a separate ticket for DELETE (#258). Let's just discuss GET over here.