Code change:
(opening this so it has a discussion venue) Currently, the spec uses "SEARCH" (for the reasons given in the spec). Alternatives: 1) pick a new name 2) use GET with payload (probably unrealistic, just listed for completeness) 3) use POST and find a way to label it as safe 4) re-use another existing safe method that takes a body (PROPFIND, REPORT) (just listed for completeness) The obvious drawback in "pick a new name" is the forseealke bike-shedding.
Just my .02. Using is initially attractive because it's familiar; effectively we'd be extending the semantics of the method with a header. However, I'm not sure it's a good idea. implies certain guarantees to clients, servers and intermediaries -- e.g., write-through. If an extension can change those guarantees, it's important that they're visible to all components, and an extension (e.g., a header) by nature can't guarantee that. It seems to me that one of the critical things to do is to get a positive indication from the user agent that the request they're sending doesn't have write-through, so a extension would need to carry an indication from the client. However, the origin server is also likely to need to convey a cache key and perhaps additional information, which leads this approach to something that's looking complex; the client has to send a certain header, the server has to send a certain header, and an intermediary still might not understand what's going on (which might be good or bad). So that makes me lean towards the status quo, (1), or (4) as being more straightforward. Reusing an already-deployed name has been discussed elsewhere; I'm not convinced that it's going to add a lot of value, considering that most traffic is HTTPS now and so intermediaries with fixed lists of supported methods are much less common. If we had data that they'd get through e.g., an enterprise virus scanning proxy whereas a new method wouldn't, I'd be interested to see that. Still, if fits the bill adequately, I think it's fine. The real test will be whether folks (especially HTTP API developers) find it compelling enough to use; I'm not sure quite gets there, but it's in the ballpark. If we're going to consider new names, I'd suggest .
If the point of this exercise is to make safe-ness visible to intermediaries, then a method is the right place to put that signal. I'm comfortable enough with , though an entirely name would be equally good. (I think that we should continue discussion about cache keys separately.)
I value a lot the ability for intermediaries to filter out write requests before they reach an application. Reusing won't have this advantage.
Interim discussion: switch document to use , which has good support from the attendees, and see how it seems to people who would be adopting.
Que? This is far more than the simple rename I was expecting. I had a similar double-take on first read, but most of the additional changes appear to be excising the WebDAV references, which is reasonable to do along with the rename.

Related discussion:
text: 2. <del> The SEARCH method is used to initiate a server-side search.  Unlike the HTTP GET method, which requests that a server return a representation of the resource identified by the target URI (as defined by RFCHTTP), the SEARCH method is used to ask the server to perform a query operation (described by the request payload) over some set of data scoped to the effective request URI.  The payload returned in response to a SEARCH cannot be assumed to be a representation of the resource identified by the effective request URI. </del> <ins> The QUERY method is used to initiate a server-side query.  Unlike the HTTP GET method, which requests that a server return a representation of the resource identified by the target URI (as defined by RFCHTTP), the QUERY method is used to ask the server to perform a query operation (described by the request payload) over some set of data scoped to the effective request URI.  The payload returned in response to a QUERY cannot be assumed to be a representation of the resource identified by the effective request URI. </ins> The body payload of the request defines the query.  Implementations <del> MAY use a request body of any content type with the SEARCH method; however, for backwards compatibility with existing WebDAV implementations, SEARCH requests that use the text/xml or application/xml media types with a root element (XML) in the "DAV:" XML namespace (XMLNS) MUST be processed per the requirements established by RFC5323. SEARCH requests are both safe and idempotent with regards to the resource identified by the request URI.  That is, SEARCH requests do </del> <ins> MAY use a request body of any content type with the QUERY method, provided that it has appropriate query semantics. QUERY requests are both safe and idempotent with regards to the resource identified by the request URI.  That is, QUERY requests do </ins> not alter the state of the targeted resource.  However, while <del> processing a search request, a server can be expected to allocate </del> <ins> processing a QUERY request, a server can be expected to allocate </ins> computing and memory resources or even create additional HTTP resources through which the response can be retrieved. <del> A successful response to a SEARCH request is expected to provide some indication as to the final disposition of the search operation.  For instance, a successful search that yields no results can be </del> <ins> A successful response to a QUERY request is expected to provide some indication as to the final disposition of the operation.  For instance, a successful query that yields no results can be </ins> represented by a 204 No Content response.  If the response includes <del> content, it is expected to describe the results of the search operation.  In some cases, the server may choose to respond indirectly to the SEARCH request by returning a 3xx Redirection with a Location header field specifying an alternate Request URI from which the search results can be retrieved using an HTTP GET request. Various non-normative examples of successful SEARCH responses are illustrated in examples. The response to a SEARCH request is not cacheable.  It ought to be noted, however, that because SEARCH requests are safe and idempotent, responses to a SEARCH MUST NOT invalidate previously cached responses </del> <ins> content, it is expected to describe the results of the operation.  In some cases, the server may choose to respond indirectly to the QUERY request by returning a 3xx Redirection with a Location header field specifying an alternate Request URI from which the results can be retrieved using an HTTP GET request.  Various non-normative examples of successful QUERY responses are illustrated in examples. The response to a QUERY request is not cacheable.  It ought to be noted, however, that because QUERY requests are safe and idempotent, responses to a QUERY MUST NOT invalidate previously cached responses </ins> to other requests directed at the same effective request URI. <del> The semantics of the SEARCH method change to a "conditional SEARCH" if the request message includes an If-Modified-Since, If-Unmodified- </del> <ins> The semantics of the QUERY method change to a "conditional QUERY" if the request message includes an If-Modified-Since, If-Unmodified- </ins> Since, If-Match, If-None-Match, or If-Range header field (RFCHTTP). <del> A conditional SEARCH requests that the query be performed only under </del> <ins> A conditional QUERY requests that the query be performed only under </ins> the circumstances described by the conditional header field(s).  It is important to note, however, that such conditions are evaluated against the state of the target resource itself as opposed to the