[dreambigwrkhard]

I'm curious too. Unless the developer is really passionate about this I don't think a dev will risk (potential) compatibility issues or unexpected footguns to use this when the workarounds do seem to work quite well already. I just dont see the benefit but maybe it's because I am just not aware of a real world use case; happy to be corrected.

[unilynx]

Elastic/Opensearch uses GET requests with a body for search, which is complicated or forbidden (not exactly sure) with the HTTP spec. Not all HTTP clients are willing to submit a body with a GET.

So opensearch also allows you to POST search requests, but those are uncacheable

QUERY would fit here perfectly - it's probably trivial for opensearch to add but it will take some time for clients to catch up.

[topham]

Fixing GET would be easier.

And yes,it would be fixing a flawed interpretation of what should be implemented.you are, by definition GETting something.

Tools dropping body from GET by default are violating the spec today.

Rules configured to drop it are just that, temporarily configured constraints readily modified.

Adding QUERY will make it unpredictable in effectively the same manner as GET/body. It'll take even longer to resolve it though.

[Yokohiii]

> Fixing GET would be easier.

I disagree. I think the adoption (or dismissal) of QUERY will show.

First thing that comes to mind is that the idempotency of GET resources are easy to handle. URL's have a fixed size, they can be efficiently hashed, cached and are unambiguous about how they serve this purpose.

It is unclear how the ecosystem will deal with the QUERY requirements. It's easy for apps, but browsers, http caches and servers will take some time to figure out solutions.

Fixing GET would have the same amount of uncertainty in addition to the need to keep current expectations valid. It's not easier, it's harder.

[topham]

Browsers won't.

No, really, they simply won't implement it.