The HTTP QUERY Method

The HTTP QUERY Method greenbytes GmbH

Hafenweg 16 Münster48155 Germany julian.reschke@greenbytes.de https://greenbytes.de/tech/webdav/

Cloudflare

jasnell@gmail.com

Akamai

mbishop@evequefou.be

Web and Internet Transport HTTP http query method This specification defines the QUERY method for HTTP. A QUERY requests that the request target process the enclosed content in a safe and idempotent manner and then respond with the result of that processing. This is similar to POST requests but can be automatically repeated or restarted without concern for partial state changes. Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at . Working Group information can be found at ; source code and issues list for this draft can be found at . The changes in this draft are summarized in .

This specification defines the HTTP QUERY request method as a means of making a safe, idempotent request () that encloses a representation describing how the request is to be processed by the target resource. A common query pattern is: GET /feed?q=foo&limit=10&sort=-published HTTP/1.1 Host: example.org However, when the data conveyed is too voluminous to be encoded in the request's URI, this pattern becomes problematic:

often size limits are not known ahead of time because a request can pass through many uncoordinated systems (but note that recommends senders and recipients to support at least 8000 octets),
expressing certain kinds of data in the target URI is inefficient because of the overhead of encoding that data into a valid URI,
request URIs are more likely to be logged than request content, and may also turn up in bookmarks,
encoding queries directly into the request URI effectively casts every possible combination of query inputs as distinct resources.

As an alternative to using GET, many implementations make use of the HTTP POST method to perform queries, as illustrated in the example below. In this case, the input to the query operation is passed as the request content as opposed to using the request URI's query component. A typical use of HTTP POST for requesting a query is: POST /feed HTTP/1.1 Host: example.org Content-Type: application/x-www-form-urlencoded q=foo&limit=10&sort=-published In this variation, however, it is not readily apparent -- absent specific knowledge of the resource and server to which the request is being sent -- that a safe, idempotent query is being performed. The QUERY method provides a solution that spans the gap between the use of GET and POST, with the example above being expressed as: QUERY /feed HTTP/1.1 Host: example.org Content-Type: application/x-www-form-urlencoded q=foo&limit=10&sort=-published As with POST, the input to the query operation is passed as the content of the request rather than as part of the request URI. Unlike POST, however, the method is explicitly safe and idempotent, allowing functions like caching and automatic retries to operate. Recognizing the design principle that any important resource ought to be identified by a URI, this specification describes how a server can assign URIs to both the query itself or a specific query result, for later use in a GET request. Summarizing: Summary of relevant method properties

	GET	QUERY	POST
Safe	yes	yes	potentially no
Idempotent	yes	yes	potentially no
URI for query itself	yes (by definition)	optional (Location response field)	no
URI for query result	optional (Content-Location response field)	optional (Content-Location response field)	optional (Content-Location response field)
Cacheable	yes	yes	yes, but only for future GET or HEAD requests
Content (body)	"no defined semantics"	expected (semantics per target resource)	expected (semantics per target resource)

This document uses terminology defined in . Furthermore, it uses the terms URI query parameter for parameters in the query component of a URI () and query content for the request content () of a QUERY request.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

The QUERY method is used to initiate a server-side query. Unlike the GET method, which requests a representation of the resource identified by the target URI (as defined by ), the QUERY method is used to ask the target resource to perform a query operation within the scope of that target resource. The content of the request and its media type define the query. The origin server determines the scope of the operation based on the target resource. Servers MUST fail the request if the Content-Type request field () is missing or is inconsistent with the request content. As for all HTTP methods, the target URI's query part takes part in identifying the resource being queried. Whether and how it directly affects the result of the query is specific to the resource and out of scope for this specification. QUERY requests are safe with regard to the target resource () -- that is, the client does not request or expect any change to the state of the target resource. This does not prevent the server from creating additional HTTP resources through which additional information can be retrieved (see Sections and ). Furthermore, QUERY requests are idempotent () -- they can be retried or repeated when needed, for instance after a connection failure. As per , a 2xx (Successful) response code signals that the request was successfully received, understood, and accepted. In particular, a 200 (OK) response indicates that the query was successfully processed and the results of that processing are enclosed as the response content.

The semantics of a QUERY request depends both on the request content and the associated metadata, such as the Media Type (). In general, any problem with requests where content and metadata are inconsistent &MUST; be rejected with a 4xx (Client Error) response (). The list below describes various cases of failures and recommends specific status codes:

A request lacking media type information by definition is incorrect and needs to fail with a 4xx status code such as 400 (Client Error).
If a media type is specified, but not supported by the resource, a 415 (Unsupported Media Type) is appropriate. This specifically includes the case where the media type is known in principle, but lacks semantics specific to a QUERY to the target resource. In both cases, the Accept-Query response field () can be used to inform the client of media types which are supported.
If a media type is specified, but is inconsistent with the actual request content, a 400 (Bad Request) can be returned. That is, a server is not allowed to infer a media type from the request content and then override a missing or "erroneous" value ("content sniffing").
If the media type is specified, is understood, and the content is indeed consistent with the type, but the query cannot be processed due to the actual contents of the query, the status 422 (Unprocessable Content) can be used. An example would be a syntactically correct SQL query that identifies a non-existent table.
Finally, if the client requests a specific response media type using the Accept field () which is not supported by the resource, a status code of 406 (Not Acceptable) is appropriate.

The equivalent resource for any given QUERY request is a resource responding to GET requests, representing that QUERY request and its target, taking both message content and metadata into account (). In particular, this includes representation metadata (), such as the content's media type. In other words, the equivalent resource is derived from the resource implementing QUERY by incorporating the request content. The term equivalent resource is used as a means to define behavior for other HTTP aspects, such as selected representations. Servers can but do not have to assign URIs to these resources (see ). If they do so, these resources will become accessible for GET requests.

A successful response (2xx, ) can include a Content-Location header field containing an identifier for a resource corresponding to the results of the operation; see for details. This represents a claim from the server that a client can send a GET request for the indicated URI to retrieve the results of the query operation just performed. The indicated resource might be temporary. See for an example.

A server can assign a URI to the equivalent resource () of a QUERY request. If the server does so, the URI of that resource can be included in the Location header field of the 2xx response (see ). This represents a claim that a client can send a GET request to the indicated URI to repeat the query operation just performed without resending the query content. This resource's URI might be temporary; if a future request fails, the client can retry using the original QUERY request target and the previously submitted content. See for an example.

In some cases, the server may choose to respond indirectly to the QUERY request by redirecting the user agent to a different URI (see ). A response with either status codes 301 (Moved Permanently, ) or 308 (Permanent Redirect, ) indicates that the target resource has permanently moved to a different URI referenced by the Location response field (). Likewise, a response with either status codes 302 (Found, ) or 307 (Temporary Redirect, ) indicates that the target resource has temporarily moved. In all four cases, the server is suggesting that the user agent can accomplish its original QUERY request by sending a similar QUERY request to the new target URI referenced by Location. Note that the exceptions for redirecting a POST as a GET request after a 301 or 302 response do not apply to QUERY requests. A response to QUERY with the status code 303 (See Other, ) indicates that the original query can be accomplished via a normal retrieval request on the URI referenced by the Location response field (). For HTTP, this means sending a GET request to the new target URI, as illustrated by the example in .

The selected representation () of a QUERY request is the same as for a GET request to the equivalent resource () of that QUERY request. A conditional QUERY requests that that selected representation (i.e., the query results, after any content negotiation) be returned in the response only under the circumstances described by the conditional header field(s), as defined in . See for examples.

The response to a QUERY method is cacheable; a cache &MAY; use it to satisfy subsequent QUERY requests as per . The cache key for a QUERY request (see ) &MUST; incorporate the request content () and related metadata (). To improve cache efficiency, caches MAY remove semantically insignificant differences first. For instance, by:

removing content encoding(s) ().
normalizing based upon knowledge of format conventions, as indicated by any media subtype suffix in the request's Content-Type field (e.g., "+json", see ).
normalizing based upon knowledge of the semantics of the content itself, as indicated by the request's Content-Type field.

Note that any such transformation is performed solely for the purpose of generating a cache key; it does not change the request itself. Clients can indicate, using the "no-transform" cache directive (), that they wish that no such transformation happens (but note that this directive is just advisory). Note that caching QUERY method responses is inherently more complex than caching responses to GET, as complete reading of the request's content is needed in order to determine the cache key. If a QUERY response supplies a Location response field () to indicate a URI for an equivalent resource (), clients can switch to GET for subsequent requests, thereby simplifying processing.

The semantics of Range Requests for QUERY are identical to those for GET, as defined in . Byte Range requests (the only range unit defined at the time of writing), however, offer little value for the results of a QUERY request. Query formats often define their own way for limiting or paging through result sets, such as with "FETCH FIRST ... ROWS ONLY" in SQL. It is expected that these built-in features will be used instead of HTTP Range Requests.

The "Accept-Query" response header field can be used by a resource to directly signal support for the QUERY method while identifying the specific query format media type(s) that may be used. Accept-Query contains a list of media ranges () using "Structured Fields" syntax (). Media ranges are represented by a List Structured Header Field of either Tokens or Strings, containing the media range value without parameters. Media type parameters, if any, are mapped to Structured Field Parameters of type String or Token. The choice of Token vs. String is semantically insignificant. That is, recipients &MAY; convert Tokens to Strings, but &MUST-NOT; process them differently based on the received type. Media types do not exactly map to Tokens, for instance they allow a leading digit. In cases like these, the String format needs to be used. The only supported uses of wildcards are "*/*", which matches any type, or "xxxx/*", which matches any subtype of the indicated type. The order of types listed in the field value is not significant. The value of the Accept-Query field applies to every URI on the server that shares the same path; in other words, the query component is ignored. If requests to the same resource return different Accept-Query values, the most recently received fresh value (per ) is used. Example: Accept-Query: "application/jsonpath", application/sql;charset="UTF-8" Although the syntax for this field appears to be similar to other fields, such as "Accept" (), it is a Structured Field and thus &MUST; be processed as specified in .

The QUERY method is subject to the same general security considerations as all HTTP methods as described in . It can be used as an alternative to passing request information in the URI (e.g., in the query component). This is preferred in some cases, as the URI is more likely to be logged or otherwise processed by intermediaries than the request content. In other cases, where the query contains sensitive information, the potential for logging of the URI might motivate the use of QUERY over GET. If a server creates a temporary resource to represent the results of a QUERY request (e.g., for use in the Location or Content-Location field), assigns a URI to that resource, and the request contains sensitive information that cannot be logged, then that URI &SHOULD; be chosen such that it does not include any sensitive portions of the original request content. Caches that normalize QUERY content incorrectly or in ways that are significantly different from how the resource processes the content can return an incorrect response if normalization results in a false positive. A QUERY request from user agents implementing CORS (Cross-Origin Resource Sharing) will require a "preflight" request, as QUERY does not belong to the set of CORS-safelisted methods (see "Methods" in ).

IANA is requested to add the QUERY method to the HTTP Method Registry at (see ). QUERY Method Definition

Method Name	Safe	Idempotent	Specification
QUERY	Yes	Yes

IANA is requested to add the Accept-Query field to the HTTP Field Name Registry at (see ). Accept-Query Field Definition

Field Name	Status	Structured Type	Reference	Comments
Accept-Query	permanent	List	of this document.

HTTP Semantics HTTP Caching Structured Field Values for HTTP Cloudflare The Varnish Cache Project Uniform Resource Identifier (URI): Generic Syntax FETCH WHATWG URL WHATWG XSL Transformations (XSLT) Version 3.0 Latest version available at .

The examples below are for illustrative purposes only; if one needs to send queries that are actually this short, it is likely better to use GET. The media type used in most examples is "application/x-www-form-urlencoded" (as used in POST requests from browser user clients, defined in "application/x-www-form-urlencoded" in ). The Content-Length fields have been omitted for brevity.

A simple query with a direct response: QUERY /contacts HTTP/1.1 Host: example.org Content-Type: application/x-www-form-urlencoded Accept: application/json select=surname,givenname,email&limit=10&match=%22email=*@example.*%22 Response: HTTP/1.1 200 OK Content-Type: application/json [ { "surname": "Smith", "givenname": "John", "email": "smith@example.org" }, { "surname": "Jones", "givenname": "Sally", "email": "sally.jones@example.com" }, { "surname": "Dubois", "givenname": "Camille", "email": "camille.dubois@example.net" } ]

A simple way to discover support for QUERY is provided by the OPTIONS () method: OPTIONS /contacts HTTP/1.1 Host: example.org Response: HTTP/1.1 200 OK Allow: GET, QUERY, OPTIONS, HEAD The Allow response field () denotes the set of supported methods on the specified resource. There are alternatives to the use of OPTIONS. For instance, a QUERY request can be tried without prior knowledge of server support. The server would then either process the request, or could respond with a 4xx status such as 405 (Method Not Allowed, ), including the Allow response field.

Discovery of supported media types for QUERY is possible via the Accept-Query () response field: HEAD /contacts HTTP/1.1 Host: example.org Response: HTTP/1.1 200 OK Content-Type: application/xhtml Accept-Query: application/x-www-form-urlencoded, application/sql Responses to which request methods will contain Accept-Query will depend on the resource being accessed. An alternative to checking Accept-Query would be to make a QUERY request, and then -- in case of a 4xx status such as 415 (Unsupported Media Type, ) response -- to inspect the Accept () response field: HTTP/1.1 415 Unsupported Media Type Content-Type: application/xhtml Accept: application/x-www-form-urlencoded, application/sql

As described in Sections and , the Content-Location and Location response fields in success responses (2xx, ) provide a way to identify alternate resources that will respond to GET requests, either for the received result of the request, or for future requests to perform the same operation. Going back to the example from : QUERY /contacts HTTP/1.1 Host: example.org Content-Type: application/x-www-form-urlencoded Accept: application/json select=surname,givenname,email&limit=10&match=%22email=*@example.*%22 Response: HTTP/1.1 200 OK Content-Type: application/json Content-Location: /contacts/stored-results/17 Location: /contacts/stored-queries/42 Last-Modified: Sat, 25 Aug 2012 23:34:45 GMT Date: Sun, 17 Nov 2024, 16:10:24 GMT [ { "surname": "Smith", "givenname": "John", "email": "smith@example.org" }, { "surname": "Jones", "givenname": "Sally", "email": "sally.jones@example.com" }, { "surname": "Dubois", "givenname": "Camille", "email": "camille.dubois@example.net" } ]

The Content-Location response field received above identifies a resource holding the result for the QUERY response it appeared on: GET /contacts/stored-results/17 HTTP/1.1 Host: example.org Accept: application/json Response: HTTP/1.1 200 OK Last-Modified: Sat, 25 Aug 2012 23:34:45 GMT Date: Sun, 17 Nov 2024, 16:10:25 GMT [ { "surname": "Smith", "givenname": "John", "email": "smith@example.org" }, { "surname": "Jones", "givenname": "Sally", "email": "sally.jones@example.com" }, { "surname": "Dubois", "givenname": "Camille", "email": "camille.dubois@example.net" } ] Note that there's no guarantee that the server will implement this resource indefinitely, so, after an error response, the client would need to redo the original QUERY request in order to obtain a new alternative location.

The Location response field identifies a resource that will respond to GET with a current result for the same process and parameters as the original QUERY request. GET /contacts/stored-queries/42 HTTP/1.1 Host: example.org Accept: application/json In this example, one entry was removed at 2024-11-17T16:12:01Z (as indicated in the Last-Modified field), so the response only contains two entries: HTTP/1.1 200 OK Content-Type: application/json Last-Modified: Sun, 17 November 2024, 16:12:01 GMT ETag: "42-1" Date: Sun, 17 Nov 2024, 16:13:17 GMT [ { "surname": "Smith", "givenname": "John", "email": "smith@example.org" }, { "surname": "Dubois", "givenname": "Camille", "email": "camille.dubois@example.net" } ] Assuming that the server still exposes the resource and that there was no change in the query result, a subsequent conditional GET request with If-None-Match: "42-1" would result in a 304 response (Not Modified, ).

Servers can send "indirect" responses () using the status code 303 (See Other, ). Given the request at the beginning of , a server might respond with: HTTP/1.1 303 See Other Content-Type: text/plain Date: Sun, 17 Nov 2024, 16:13:17 GMT Location: /contacts/stored-queries/42 See stored query at "/contacts/stored-queries/42". This is similar to including Location on a direct response, except that no result for the query is returned. This allows the server to only generate or reuse an alternative resource. This resource could then be used as shown in .

Consider a resource implementing QUERY that supports "application/sql" and "application/xslt+xml" () as request media types, and which can generate responses as "text/csv". The data set being queried contains RFC document information, and the query returns information grouped by decade: QUERY /rfc-index.xml HTTP/1.1 Host: example.org Date: Sun, 7 Sep 2025, 00:00:00 GMT Content-Type: application/xslt+xml Accept: text/csv ...Query content using XSLT... Response: HTTP/1.1 200 OK Date: Sun, 7 Sep 2025, 00:00:00 GMT Location: /stored-queries/4815162342 Content-Type: text/csv Accept-Query: "application/sql", "application/xslt+xml" Last-Modified: Sun, 31 Aug 2025, 08:44:00 GMT Vary: Accept-Query, Content-Encoding, Content-Type decade, total, with errata, % with errata, average page count 1960, 26, 5, 19.2, 5.3 1970, 666, 18, 2.7, 6.1 1980, 376, 44, 11.7, 23.4 1990, 1593, 269, 16.9, 25.5 2000, 2888, 1048, 36.3, 27.3 2010, 2954, 895, 30.3, 26.1 2020, 1133, 230, 20.3, 26.2 Here, the server has assigned the path "/stored-queries/4815162342" to the equivalent resource () for subsequent use with GET. Later on, the client repeats the query, but specifies that results should only be returned when changed: QUERY /rfc-index.xml HTTP/1.1 Host: example.org Date: Mon, 8, Sep 2025, 11:00:00 GMT Content-Type: application/sql Accept: text/csv If-Modified-Since: Sun, 31 Aug 2025, 08:44:00 GMT Vary: Accept-Query, Content-Type ...Same query, but using SQL... The data being queried did not change, therefore the server responds with: HTTP/1.1 304 Not Modified Date: Mon, 8 Sep 2025, 11:00:00 GMT Content-Type: text/csv Location: /stored-queries/4815162342 Accept-Query: "application/sql", "application/xslt+xml" Last-Modified: Sun, 31 Aug 2025, 08:44:00 GMT Vary: Accept-Query, Content-Type As the server identified a URI for the equivalent resource, that resource can be accessed with GET. In particular, this avoids re-sending the query request's content: GET /stored-queries/4815162342 HTTP/1.1 Host: example.org Date: Sun, 21, Sep 2025, 12:08:00 GMT Accept: text/csv If-Modified-Since: Sun, 31 Aug 2025, 00:00:00 GMT Here, the state of the data set indeed changed, so new content is returned: HTTP/1.1 200 OK Date: Sun, 21, Sep 2025, 12:08:00 GMT Content-Type: text/csv Last-Modified: Thu, 18 Sep 2025, 19:56:00 GMT Vary: Accept-Query, Content-Encoding, Content-Type decade, total, with errata, % with errata, average page count 1960, 26, 5, 19.2, 5.3 1970, 666, 18, 2.7, 6.1 1980, 376, 44, 11.7, 23.4 1990, 1593, 269, 16.9, 25.5 2000, 2888, 1048, 36.3, 27.3 2010, 2954, 895, 30.3, 26.1 2020, 1133, 230, 20.3, 26.2 (Note the change in the row for this decade.) The diagrams below illustrate the use of conditional requests and how they can differ when a URI is assigned to the equivalent resource (and when the client is taking advantage of it). The fictitious field name "Validator" is used for demonstration purposes.

| | | | 200 OK | | Validator: foo | |<----------------------------------------+ | | | QUERY with content | | (conditional on 'foo') | +---------------------------------------->| | | | 304 Not Modified | | Validator: foo | |<----------------------------------------+ | | | +--------------+ | | State Change | | +--------------+ | | | QUERY with content | | (conditional on 'foo') | +---------------------------------------->| | | | 200 OK | | Validator: bar | |<----------------------------------------+ | |]]>

| (generates /xyz) | +---------------------------o | | | | 200 OK | | | Validator: foo | | | Location: /xyz | | |<------------------------------+ | | | | | GET | | (conditional on 'foo') | +---------------------------------------------------------->| | | | 304 Not Modified | | Validator: foo | |<----------------------------------------------------------+ | | | +--------------+ | | State Change | | +--------------+ | GET | | (conditional on 'foo') | +---------------------------------------------------------->| | | | 200 OK | | Validator: bar | |<----------------------------------------------------------+ | |]]>

The following examples show requests on a JSON-shaped () database of RFC errata. The request below uses XSLT to extract errata information summarized per year and the defined errata types. QUERY /errata.json HTTP/1.1 Host: example.org Content-Type: application/xslt+xml Accept: application/xml, text/csv errata_status_code submit_date ]]> Response: HTTP/1.1 200 OK Content-Type: text/csv Accept-Query: "application/jsonpath", "application/xslt+xml" Date: Wed, 19 Feb 2025, 17:10:01 GMT year, total, rejected, verified, hdu, reported 2000, 14, 0, 14, 0, 0 2001, 72, 1, 70, 1, 0 2002, 124, 8, 104, 12, 0 2003, 63, 0, 61, 2, 0 2004, 89, 1, 83, 5, 0 2005, 156, 10, 96, 50, 0 2006, 444, 54, 176, 214, 0 2007, 429, 48, 188, 193, 0 2008, 423, 52, 165, 206, 0 2009, 331, 39, 148, 144, 0 2010, 538, 80, 232, 222, 4 2011, 367, 47, 170, 150, 0 2012, 348, 54, 149, 145, 0 2013, 341, 61, 169, 106, 5 2014, 342, 73, 180, 72, 17 2015, 343, 79, 145, 89, 30 2016, 295, 46, 122, 82, 45 2017, 303, 46, 120, 84, 53 2018, 350, 61, 118, 98, 73 2019, 335, 47, 131, 94, 63 2020, 387, 68, 117, 123, 79 2021, 321, 44, 148, 63, 66 2022, 358, 37, 198, 40, 83 2023, 262, 38, 121, 33, 70 2024, 322, 33, 125, 23, 141 9999, 1, 0, 0, 1, 0 Note the Accept-Query response field indicating that another query format -- JSONPath () -- is supported as well. The request below would report the identifiers of all rejected errata submitted since 2024: QUERY /errata.json HTTP/1.1 Host: example.org Content-Type: application/jsonpath Accept: application/json $..[ ?@.errata_status_code=="Rejected" && @.submit_date>"2024" ] ["doc-id"] Response: HTTP/1.1 200 OK Content-Type: application/json Accept-Query: "application/jsonpath", "application/xslt+xml" Date: Thu, 20 Feb 2025, 09:55:42 GMT Last-Modified: Thu, 20 Feb 2025 06:10:01 GMT [ "RFC1185","RFC8407","RFC6350","RFC8467","RFC1157","RFC9543", "RFC9076","RFC7656","RFC2822","RFC9460","RFC2104","RFC6797", "RFC9499","RFC9557","RFC2131","RFC2328","RFC9001","RFC3325", "RFC9438","RFC2526","RFC2985","RFC7643","RFC9132","RFC6376", "RFC9110","RFC9460","RFC7748","RFC9497","RFC8463","RFC4035", "RFC7239","RFC9083","RFC9537","RFC9537","RFC9420","RFC9000", "RFC9656","RFC9110","RFC2324","RFC2549","RFC6797","RFC2549", "RFC8894" ]

The HTTP Method Registry () already contains three other methods with the properties "safe" and "idempotent": "PROPFIND" (), REPORT" (), and "SEARCH" (). It would have been possible to re-use any of these, updating it in a way that it matches what this specification defines as the new method "QUERY". Indeed, the early stages of this specification used "SEARCH". The method name "QUERY" ultimately was chosen because:

The alternatives use a generic media type for the request content ("application/xml"); the semantics of the request depends solely on the request content.
Furthermore, they all originate from the WebDAV activity, about which many have mixed feelings.
"QUERY" captures the relation with the URI's query component well.

Use "example/query" media type instead of undefined "text/query" ()
In , adjust the grammar to just define the field value ()
Update to latest HTTP core spec, and adjust terminology accordingly ()
Reference RFC 8174 and markup bcp14 terms ()
Update HTTP reference ()
Relax restriction of generic XML media type in request content ()

Add minimal description of cacheability ()
Use "QUERY" as method name ()
Update HTTP reference ()

In , slightly rephrase statement about significance of ordering ()
Throughout: use "content" instead of "payload" or "body" ()
Updated references ()

In , clarify scope ()

Describe role of Content-Location and Location fields ()
Added Mike Bishop as author ()
Use "target URI" instead of "effective request URI" ()

Updated language and examples about redirects and method rewriting ()
Add QUERY example to introduction ()
Update "Sensitive information in QUERY URLs" ()
Field registration for "Accept-Query" ()

Improve language about sensitive information in URIs ()
Guidance about what's possible with GET wrt URI length ()
Clarified description of conditional queries ()
Editorial changes to Introduction (ack Will Hawkins, )
Added Security Consideration with respect to Normalization ()
Added CORS considerations ()
Make Accept-Query a Structured Field ()
SQL media type is application/sql (RFC6922) ()
Added overview table to introduction ()
Reference HTTP spec for terminology ()
Moved BCP14 related text into subsection ()
Move examples into index ()

Examples Section revised ()
Discuss Range Requests ()

Mention the role of the query part of the request URI ()
Avoid term 'query parameters' ()
Add missing references, fixed terminology ()
Add Acknowledgements/Contributors sections; moved Ashok to Contributors ()
Hopefully more clarity wrt query content vs URI query component ()

Clarify cacheability of POST ()
Rephrase text that suggests a media type definition can override URI semantics ()
Restrict description of Content-Location and Location semantics to 2xx responses ()
Slightly rephrase semantics for Content-Location ()

Editorial nits (, ack martinthomson)
Fix references in (, ack Rahul Gupta)
Update James' affiliation ()
Review references to HTTP ()
Address most Rahul Gupta's additional feedback ()

Improve description of caching, clarifying what is required ()
Address HTTPDIR/RF feedback on example appendix ()
Address HTTPDIR/RF feedback on redirection ()
Address HTTPDIR/RF feedback on caching ()
Address HTTPDIR/RF feedback on abstract ()
Address HTTPDIR/RF feedback on introduction ()
Address HTTPDIR/RF feedback on method definition ()
Consistent Table Captions ()
Define "Equivalent Resource", update description of Conditional Requests, add examples ()
Extend discussion of Range Requests ()

Ack Asbjørn Ulsberg ()
LC feedback from Rahul Gupta ()

URI reference is normative ()
inconsistency between Sections 2.4 and 4 wrt URI assignments ()
IESG review nits ()
Explain relation to SEARCH etc ()

We thank all members of the HTTP Working Group for ideas, reviews, and feedback. The following individuals deserve special recognition: Carsten Bormann, Mark Nottingham, Martin Thomson, Michael Thornburgh, Roberto Polli, Roy Fielding, and Will Hawkins.

Ashok Malhotra participated in early discussions leading to this specification:

malhotrasahib@gmail.com

Discussion on the this HTTP method was reopened by Asbjørn Ulsberg during the HTTP Workshop in 2019:

asbjorn@ulsberg.no https://asbjor.nu/