Code change:
This variation, however, suffers from the same basic limitation as GET in that it is not readily apparent -- absent specific knowledge of the resource and server to which the request is being sent -- that <del> a search operation is what is being requested.  Web applications use the POST method for a wide variety of uses including the creation or modification of existing resources.  Sending the request above to a different server, or even repeatedly sending the request to the same server could have dramatically different effects. </del> <ins> a safe, idempotent query is being performed. </ins> <del> The SEARCH method provides a solution that spans the gap between the </del> <ins> The QUERY method provides a solution that spans the gap between the </ins> use of GET and POST.  As with POST, the input to the query operation is passed along within the payload of the request rather than as part <del> of the request URI.  Unlike POST, however the semantics of the SEARCH method are specifically defined. </del> <ins> of the request URI.  Unlike POST, however, the method is explicitly safe and idempotent, allowing functions like caching and automatic retries to operate. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and

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).