Code change:
The issue discussion also mentioned the ability for the server to indicate a GET-able URI for the returned results, presumably using Content-Location. It looks like the definition in -semantics is probably sufficient, but it's probably worth highlighting that there are caching implications to having that header present in one of these responses.
Content-Location doesn't have any effect on caching. It would be odd to add caching implications to it.
NAME I was recalling this: URL thinking that the response should be cached for the indicated resource. But I had missed this: And indeed, the Caching spec talks only about invalidating any existing entry for the indicated resource, rather than giving any permission to cache the response under that URI. The application is allowed to update its local copy based on Content-Location, but apparently caches aren't.
We should figure out/document: 1) Establishing the cache key - a cache needs to know how to compute a cache key for the request. The obvious (and very inefficient) way to do this is to use the entire request body as part of the key. 2) Request canonicalisation - we should allow caches with knowledge of canonicalisation algorithms for a given format to use them. 3) Indicating canonical form in requests - if a client (UA or intermediary) canonicalises, it would be nice if they could assert that in the request, so a downstream cache can assume it's there and just look for a byte-for-byte match, rather than re-canonicalising. This would allow a client to manufacture cache misses, but that's already possible in URLs... 4) Indicating cache key in requests - E.g., a hash of the request body. Needs security analysis, though. 5) Indicating cache key in responses - If the server can instruct caches as to what future requests would match it, that would be very advantageous. Necessarily requires knowledge of the request format, but we could define common ones for url encode, XML, JSON.
I don't think that (4) is generally feasible. There might be cases where a cache trusts other entities sufficiently that a hash (Digest field?) can be used, but it will need to work this out for itself. This is probably the big cost associated with caching this method. 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). For this use case, we just need a way for the server to also point to a GETtable resource (maybe with a lifetime). If we solved that problem, would we still need full cacheability?
Needs to sync with .

Related discussion:
text: 1. <del> This specification updates the HTTP SEARCH method originally defined in RFC5323. </del> <ins> This specification defines the HTTP QUERY request method as a means of making a safe, idempotent request that contains content. </ins> <del> Many existing HTTP-based applications use the HTTP GET and POST methods in various ways to implement the functionality provided by SEARCH. </del> <ins> Most often, this is desirable when the data conveyed in a request is too voluminous to be encoded into the request's URI.  For example, while this is an common and interoperable query: </ins> <del> Using a GET request with some combination of query parameters included within the request URI (as illustrated in the example below) is arguably the most common mechanism for implementing search in web applications.  With this approach, implementations are required to parse the request URI into distinct path (everything before the '?') and query elements (everything after the '?').  The path identifies the resource processing the query (in this case 'http://example.org/ feed') while the query identifies the specific parameters of the search operation. </del> <ins> if the query parameters extend to several kilobytes or more of data it may not be, because many implementations place limits on their size.  Often these limits are not known or discoverable ahead of time, because a request can pass through many uncoordinated systems. Additionally, expressing some data in the target URI is inefficient, because it needs to be encoded to be a valid URI. </ins> <del> A typical use of HTTP GET for requesting a search While there are definite advantages to using GET requests in this manner, the disadvantages should not be overlooked.  Specifically: </del> <ins> Encoding query parameters directly into the request URI also effectively casts every possible combination of query inputs as distinct resources.  Depending on the application, that may not be desirable. </ins> As an alternative to using GET, many implementations make use of the HTTP POST method to perform queries, as illustrated in the example