This seems reasonable, but unlikely to happen. GET is already pretty much sufficient, especially given that clients generally support megabytes worth of query strings in these modern times. If we're doing this though, I'll cast my vote for naming it more semantically as QUERY, and forgoing whatever little WebDAV compatibility would be had otherwise.
I understand the benefits of QUERY over GET because GET is expected to return a resource in the response. Why not just use POST though? Send a post message to a server asking to conduct a search and sending the results of that query in the response?
QUERY is the one missing method to cover all reasonable combinations of safe/idempotent/neither and whether (if safety or idempotency applies) a body needs taken into account to identify a semantically identical request.
Not idempotent: POST
idempotent/not safe: PUT (body matters), DELETE (no body)
safe: QUERY (body matters)/GET (no body)
That’s why QUERY is needed. POST is not a good substitute.
QUERY would be more compatible with WebDAV as the would be no confusion. The relevant compatibility is with middle boxes like proxy servers that mostly already forward SEARCH but would block QUERY.
In an enterprise setting you can just roll out your own root certificate to every machine's trust store, and have your middle box MitM all traffic with the help of that.
