[DaiPlusPlus]

Many “WAF” (Web-Application Firewalls) and reverse-proxies are configured to block “unusual” traffic though, including GET-with-body - but I feel that this approach is like how (around 2000-2006) everyone switched from high-performance or legacy binary protocols to XML/SOAP-over-HTTPS to avoid corporate firewall headaches.

[thwarted]

There will most likely be problems with such web-application firewalls anyway, since those same firewalls will probably reject HTTP methods that they don't know about.

But adding a new new method is probably overall better and matches people's understanding of the implementation and interpretation of GET, even if (with extensions) GET can have a body people don't think of it like that. So a new method with defined semantics and interpretation avoids a whole bunch of sideshow debate about if GET with a body is possible or appropriate.

[mgaunard]

It's not up to debate, GET does allow a body.

[thwarted]

You can make all noise you want about how it's not up for debate because of what the standard says, and said noise does not avoid sideshow bs debates about the how it is used and restricted/limited in practice. A new method avoids that because a new method comes with exactly zero historical baggage.

[mgaunard]

A new method does not give any advantage over extending an existing method, it's going to have to use the same code anyway.

[preseinger]

GET allows, but does not require, server implementations to read/parse a body

sending a body with a GET request does not suggest the recipient server will receive that body, in general