Re: GET / DELETE request bodies

[Cory Benfield <[e-mail]>]

On Mon, 17 Feb 2020 at 18:44, Roy T. Fielding <[e-mail]> wrote:
>
> > On Feb 17, 2020, at 1:53 AM, Cory Benfield <[e-mail]> wrote:
> >
> > The semantic requirement missing is that DELETE bodies have no
> > spec-defined semantics. This is not that they can't have semantics, or
> > that they shouldn't have spec-defined semantics, only that no
> > specification has ever said what a body in a DELETE request means.
>
> FTR, this is a common misinterpretation, but that is not what it says and
> certainly not what it means.
>
> They have no semantics in the sense that a body cannot change the meaning
> of a received request. They are absolutely forbidden to have any impact
> whatsoever on the processing or interpretation of the request aside from
> the necessity to read and discard the bytes received in order to maintain
> the message framing. The only reason we didn't forbid sending a body is
> because that would lead to lazy implementations assuming no body would
> be sent.
>
> This has always been the case for HTTP and GET/HEAD/PUT/DELETE.
> They were defined that way so that the URL would identify the resource
> and intermediaries would not have to delve into the body to reinterpret
> the semantics defined by method and header fields.

I'm finding this...confusing. Did you mean to put PUT in that list?
Because RFC 7231 doesn't say bodies in PUT have no defined semantics,
and it's distinctly not like the others in your list. Was CONNECT what
you had in mind instead?

The requirement to handle the body seems covered by RFC 7230 § 3.3:

> Request message framing is independent of method semantics, even if the method does
> not define any use for a message body.

But your forceful response on this seems to be out of line with the
highly equivocal language in the RFC. It would have cost nothing for
the RFC, instead of saying "A payload within a GET request has no
defined semantics", to say "A payload in a GET request MUST be
ignored". This doesn't forbid sending it, just forbids doing anything
with it, and seems closer to your intent.

Are you open to considering a work item for the next round of drafts
to consider adding normative language that matches your position on
request bodies?