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: (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 .