Defining a new HTTP method: HTTP SEARCH

Counter to some of the other comments (thus far), I&#x27;m on board with this as a method.<p>With the correct header variables, such as Accept-Content, we can settle on nice standardised database querying <i>over the web</i>. Think beyond web pages, and think about proper client-server applications, where the developer doesn&#x27;t have to re-invent the wheel, or use a framework that may not be in use or supported a few years down the line.<p>Imagine using curl to do a HTTP SEARCH and piping the response directly into your app or other command line tools. No time wasted developing or installing supporting libraries - it just <i>works</i>.<p>Edit: Now I think about it, maybe SEARCH is the wrong name. Using SQL as a [bad] example, it would be odd to use HTTP <i>SEARCH</i> to do an insert or update query.

This is all downside for no upside. The stated problem to solve -- that it&#x27;s hard to fit search criteria into query string parameters -- is not really any sort of real problem in practice.<p>This would have us forgo cacheability, forgo the ability to send a link to a search, introduce more complexity into web servers and clients, all just to be able to send query parameters in the request body.

&gt; Right now the spec does not define the result of this query as cacheable. It&#x27;s not completely clear why<p>That was the unique selling point of SEARCH over POST though.<p>How about using the Range header with a custom value domain instead?

I&#x27;m surprised not to see this mentioned, but Elasticsearch allows searching over GET with a request body. I believe that GET-with-body is not standard but works great in practice. It allows one to put Elasticsearch behind a proxy that only allows GET, to give customers read-only access.<p>[edit: or maybe it&#x27;s standard but not REST-compliant?]

Seems like it could be a nice addition,<p>I like the concept in general, like a GET w&#x2F; data or a cacheable POST, meant to query&#x2F;retrieve information so you have a semantic distinction for that as well.

Are proxies even relevant anymore with HTTPS? The only two scenarios I can imagine are reverse proxies at the server&#x27;s side (which the server controls), and corporate MITMing firewalls (which I personally think are the plaugue and don&#x27;t belong in 2021).