A situational issue that I've run into a number of times with GET is various middle boxes inadvertently logging sensitive data that was in the query string of a GET. By sensitive data, I mean PII and CU information. While we have used POST to side step the issue, it'd be nice if there was a more appropriate method.

But a new HTTP method would require an update to the middle boxes... if you're doing that, you could also consider updating them to avoid the issue you described.

Overall, I'm not necessarily inherently against new HTTP methods. If equipment that is supposed to be transparent to HTTP isn't, should be solved elsewhere, not by a new HTTP method.

There's no button you can press to get all middleboxes updated.

It's better to fail on the ones that slip through the cracks than to leak data. And the failure alerts people that updates are needed here.

Many logging systems exclude query parameters from the logging by default. It is also fine to include PII data in the logs as long as they are handled correctly and deleted after 30 days. But I have got burned by this problem as well. Like people using PIIs for identifiers.

> I don't see any problems with large query params.

Most servers will reject URLs after a certain size, 4-8KB.

This is correct, and one only needs to consider the impact of large or unlimited length urls on server memory consumption per request to see that a relatively small limit is desirable and even necessary.

Depends. But moving the payload between the body and the query will not solve anything performance wise if you design for it.

A query of that size will likely not benefit from a GET anyway so use a POST.

Sure except POST has its own set of issues - like not being cachable. But SEARCH or QUERY can be cached safely!

I’m pretty sure most browsers have fairly low limits for uri length.