Subject: GET / DELETE request bodies

From: Rob Sayre <[email-masked]>
Date: Wed, 12 Feb 2020 00:26:38 -0800

Hi,

I saw

https://github.com/httpwg/http-core/pull/300

It's true that the semantics here aren't defined, but I've generally seen
this stuff used when the request data won't fit in the request line.

What semantic requirement is missing vs the request line? Some carriage
returns?

thanks,
Rob

---

From: Cory Benfield <[email-masked]>
Date: Mon, 17 Feb 2020 09:53:57 +0000

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.
They never have. The result of this is that DELETES with bodies aren't
interoperable: while they may work with a specific service, that
service has defined a special-case for itself. Arbitrary
implementations are free to ignore DELETE requests with bodies, or
reject them, or do anything else they like with them.

The relevant section of the HTTP specification that discusses what it
means for a message body to have semantics is RFC 7231 § 3.3 (Payload
Semantics) (https://tools.ietf.org/html/rfc7231#section-3.3).

On Wed, 12 Feb 2020 at 08:30, Rob Sayre <[email-masked]> wrote:
> It's true that the semantics here aren't defined, but I've generally seen this stuff used when the request data won't fit in the request line.
>
> What semantic requirement is missing vs the request line? Some carriage returns?
>
> thanks,
> Rob

---

From: Julian Reschke <[email-masked]>
Date: Mon, 17 Feb 2020 13:59:34 +0100

On 17.02.2020 10:53, Cory Benfield wrote:
> ...

I personally find that line of argument incredibly weak.

1.) What about OPTIONS then? I don't see a significant difference
between the warnings that we have for OPTIONS ("not defined here but may
be in the future") and DELETE ("has no defined semantics so might be
rejected") - in particular as the latter statement was a change from 2616...

2) We *claim* that DELETE with request body is not interoperable; but do
we actually have proof of that? What problem are we solving by making
this change?

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 17 Feb 2020 10:44:25 -0800

> On Feb 17, 2020, at 1:53 AM, Cory Benfield <[email-masked]> wrote:
> 

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.

The other request methods are more like POST and the original SEARCH.
OPTIONS was defined much later with the intent of maybe needing a
body for more complex queries, but we didn't have the energy or need
to actually define one.

....Roy

---

From: Rob Sayre <[email-masked]>
Date: Tue, 18 Feb 2020 12:34:01 -0800

> because that would lead to lazy implementations assuming no body would

This text on message framing seems clearer to me than what's in the draft,
but vague references to "semantics" in web specs drive me nuts. Maybe no
one else cares. :)

thanks,
Rob

---

From: Roberto Polli <[email-masked]>
Date: Tue, 18 Feb 2020 23:33:58 +0100

Dear all,

> but vague references to "semantics" in web specs drive me nuts. Maybe no

I think that the above text should be in the specifications. That will make
the web a better place.

Peace,
R

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 19 Feb 2020 04:29:26 +0100

> I think that the above text should be in the specifications. That will make

Well, it is more or less implied when you check 7230 and 7231 together,
but I agree that having such a single prominent sentence somewhere would
make it clear to the casual reader that framing requires to support this
even though you should not expect to rely on that data.

Willy

---

From: Cory Benfield <[email-masked]>
Date: Mon, 24 Feb 2020 16:19:13 +0000

> 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?

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 24 Feb 2020 09:32:49 -0800

> On Feb 24, 2020, at 8:19 AM, Cory Benfield <[email-masked]> wrote:

We tried that and people chose to interpret "ignored" as "do not parse".

> to consider adding normative language that matches your position on

There are closed issues for GET and DELETE:

  https://github.com/httpwg/http-core/issues/202

  https://github.com/httpwg/http-core/issues/258

which were merged for the next drafts:

  https://github.com/httpwg/http-core/pull/300/files

If that language is still not enough, then we can reopen them on review.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 24 Feb 2020 10:13:28 -0800

> On Mon, 17 Feb 2020 at 18:44, Roy T. Fielding <[email-masked] <mailto:[email-masked]>> wrote:
>> 

Er, no, I was thinking about the 1:1 relationship in the identifier and made that all confusing ...
PUT sends a representation in the request body, so the body exists but does not change the
semantics of PUT.  PATCH and POST would be the counterexamples where the recipient has to
process the body in order to determine the request semantics.  CONNECT is just weird.

....Roy

---

From: Cory Benfield <[email-masked]>
Date: Tue, 25 Feb 2020 09:13:07 +0000

Thanks Roy, this language seems like a reasonable compromise position.

Of course, I expect it to be roundly ignored given how many HTTP
implementations currently use bodies on these requests today, but it's
nice to try to define the correct thing even if it isn't widely done.
For my part: https://github.com/apple/swift-nio/issues/1414.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 25 Feb 2020 11:05:51 +0100

> nice to try to define the correct thing even if it isn't widely done.

(devil's advocate) If they use request bodies here, doesn't that mean
interop is quite good? Again, what problem are we solving by forbidding
them?

Best regards, Julian