W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2020

Re: GET / DELETE request bodies

From: Cory Benfield <cory@lukasa.co.uk>
Date: Fri, 6 Mar 2020 08:28:02 +0000
Message-ID: <CAH_hAJHdYxMnv8UoW6Y=WgRwMouhcWHrgYiGbFePTOCVrQnFGw@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, Rob Sayre <sayrer@gmail.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On Tue, 25 Feb 2020 at 10:05, Julian Reschke <julian.reschke@gmx.de> wrote:
>
> On 25.02.2020 10:13, Cory Benfield wrote:
> > 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.
>  > ...
>
> (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


I think this is a perfectly valid question. It was not clear to me
that there was an outstanding problem with supplying request bodies on
these requests, which is why my original response said "eh an
arbitrary endpoint won't understand them but if you control all the
endpoints then you can just do what you want". This is the
currently-used model for bodies in these requests.

On the other hand, I think Roy's argument (that in general bodies on
these requests are going to be ignored) is not unreasonable either.
After all, if you control all the endpoints you can just diverge from
the HTTP RFCs in any way you wish and nothing bad will happen. The
HTTP RFCs are only relevant where you care about what arbitrary other
protocol participants will do in the face of your message. I still
wish the new language were even clearer, and said something closer to
what Roy originally said in this thread, but I understand why we'd add
this language to the spec.
Received on Friday, 6 March 2020 08:28:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 6 March 2020 08:28:29 UTC