- From: Cory Benfield <cory@lukasa.co.uk>
- Date: Fri, 6 Mar 2020 08:28:02 +0000
- 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