Code change:
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 to other requests directed at the same effective request URI. The semantics of the SEARCH method change to a "conditional SEARCH" if the request message includes an If-Modified-Since, If-Unmodified- </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 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 collected results of the search operation. <ins> 2.1. The response to a QUERY method is cacheable; a cache MAY use it to satisfy subsequent QUERY requests as per HTTP-CACHING). The cache key for a query (see HTTP-CACHING) MUST incorporate the request content.  When doing so, caches SHOULD first normalize request content to remove semantically insignificant differences, thereby improving cache efficiency, by: Note that any such normalization is performed solely for the purpose of generating a cache key; it does not change the request itself. </ins> 3. <del> The "Accept-Search" response header field MAY be used by a server to directly signal support for the SEARCH method while identifying the specific query format media types that may be used. </del> <ins> The "Accept-Query" response header field MAY be used by a server to directly signal support for the QUERY method while identifying the specific query format media type(s) that may be used. </ins> <del> The Accept-Search header field specifies a comma-separated listing of </del> <ins> The Accept-Query header field specifies a comma-separated listing of </ins> media types (with optional parameters) as defined by RFCHTTP. <del> The order of types listed by the Accept-Search header field is </del> <ins> The order of types listed by the Accept-Query header field is </ins> insignificant. 4.

Related discussion:
text: As for the general case of c14n, it's unfortunate that this is necessary, but it is probably better than relying on having some shared understanding of an abstract model for the resource representation. I would not build this on any assumption that XML c14n is possible. A complete solution there is likely impossible. I know less about the warts of JSON, but even that is entering into dangerous territory. You might get more traction with schema-aware c14n with the understanding that it is not generally applicable to any document. That is, define tools so that specific XML- or JSON-based formats can opt in to the use of c14n. People might then apply that c14n if the format allows it; people might also apply the c14n if the format does not, but we have not promised them anything and so guarantees might not apply.
nod there's going to be a tradeoff between the amount of knowledge/processing necessary for c14n and cache efficiency. It might be good to explore what conventions a format needs to follow to make it easily canonical; I can't help but think that most use cases for this are going to be defining a new query language, not reusing an existing document or even data format.
I think that caching is a "must have", though probably we could just provide minimal hints and leave clients the onus of hitting the cache (eg. clients c14n-izing requests in some may increase cache hits). I won't mess with the request media-type (json? xml? x-www-form-urlencoded? ...) and just use the content checksum (eg. ). I think that supporting media-type aware caches is really hard to implement (eg. see rfc8785 and rfc7493 only for json): there's room for experimental specs though... That's ok, though see (2) about supporting media-types is hard Agree wrt Security Considerations IF we want to support a caching based on a response cache key, this could be implemented with some caveats without re-sending the at all: Authentication information should be processed; MUST NOT contain authnz information
Caching will be tricky for "similar" requests sent by different clients. On the other hand, caching could be simple for requests that are repeated by the same client (like in a refresh operation).