draft-ietf-httpbis-safe-method-w-body-14.txt		draft-ietf-httpbis-safe-method-w-body-latest.txt
	HTTP Working Group J. Reschke		httpbis Working Group J. Reschke
	Internet-Draft greenbytes		Internet-Draft greenbytes
	Intended status: Standards Track J.M. Snell		Intended status: Standards Track J.M. Snell
	Expires: May 22, 2026 Cloudflare		Expires: December 31, 2026 Cloudflare
	M. Bishop		M. Bishop
	Akamai		Akamai
	November 18, 2025		June 29, 2026
	The HTTP QUERY Method		The HTTP QUERY Method
	draft-ietf-httpbis-safe-method-w-body-14		draft-ietf-httpbis-safe-method-w-body-latest
	Abstract		Abstract
	This specification defines the QUERY method for HTTP. A QUERY		This specification defines the QUERY method for HTTP. A QUERY
	requests that the request target process the enclosed content in a		requests that the request target process the enclosed content in a
	safe and idempotent manner and then respond with the result of that		safe and idempotent manner and then respond with the result of that
	processing. This is similar to POST requests but can be		processing. This is similar to POST requests, but QUERY requests can
	automatically repeated or restarted without concern for partial state		be automatically repeated or restarted without concern for partial
	changes.		state changes.
	Editorial Note		Editorial Note
	This note is to be removed before publishing as an RFC.		This note is to be removed before publishing as an RFC.
	Discussion of this draft takes place on the HTTP working group		Discussion of this draft takes place on the HTTP working group
	mailing list (ietf-http-wg@w3.org), which is archived at		mailing list (ietf-http-wg@w3.org), which is archived at
	<https://lists.w3.org/Archives/Public/ietf-http-wg/>.		<https://lists.w3.org/Archives/Public/ietf-http-wg/>.
	Working Group information can be found at <https://httpwg.org/>;		Working Group information can be found at <https://httpwg.org/>;
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 10 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on May 22, 2026.		This Internet-Draft will expire on December 31, 2026.
	Copyright Notice		Copyright Notice
	Copyright (c) 2025 IETF Trust and the persons identified as the		Copyright (c) 2026 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	1.2. Notational Conventions . . . . . . . . . . . . . . . . . 5		1.2. Notational Conventions . . . . . . . . . . . . . . . . . 5
	2. QUERY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. QUERY Method . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Media Types and Content Negotiation . . . . . . . . . . . 6		2.1. Media Types and Content Negotiation . . . . . . . . . . . 6
	2.2. Equivalent Resource . . . . . . . . . . . . . . . . . . . 7		2.2. Equivalent Resource . . . . . . . . . . . . . . . . . . . 7
	2.3. Content-Location Response Field . . . . . . . . . . . . . 8		2.3. Content-Location Response Field . . . . . . . . . . . . . 8
	2.4. Location Response Field . . . . . . . . . . . . . . . . . 8		2.4. Location Response Field . . . . . . . . . . . . . . . . . 8
	2.5. Redirection . . . . . . . . . . . . . . . . . . . . . . . 8		2.5. Redirection . . . . . . . . . . . . . . . . . . . . . . . 8
	2.6. Conditional Requests . . . . . . . . . . . . . . . . . . 9		2.6. Conditional Requests . . . . . . . . . . . . . . . . . . 9
	2.7. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 9		2.7. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 9
	2.8. Range Requests . . . . . . . . . . . . . . . . . . . . . 10		2.8. Range Requests . . . . . . . . . . . . . . . . . . . . . 10
	3. The "Accept-Query" Header Field . . . . . . . . . . . . . . . 10		3. The Accept-Query Header Field . . . . . . . . . . . . . . . . 10
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 11		4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	5.1. Registration of QUERY method . . . . . . . . . . . . . . 12		5.1. Registration of the QUERY Method . . . . . . . . . . . . 12
	5.2. Registration of Accept-Query field . . . . . . . . . . . 12		5.2. Registration of the Accept-Query Field . . . . . . . . . 12
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	6.1. Normative References . . . . . . . . . . . . . . . . . . 12		6.1. Normative References . . . . . . . . . . . . . . . . . . 12
	6.2. Informative References . . . . . . . . . . . . . . . . . 13		6.2. Informative References . . . . . . . . . . . . . . . . . 13
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14
	A.1. Simple Query . . . . . . . . . . . . . . . . . . . . . . 14		A.1. Simple Query . . . . . . . . . . . . . . . . . . . . . . 14
	A.2. Discovery of QUERY support . . . . . . . . . . . . . . . 15		A.2. Discovery of QUERY Support . . . . . . . . . . . . . . . 15
	A.3. Discovery of QUERY Formats . . . . . . . . . . . . . . . 15		A.3. Discovery of QUERY Formats . . . . . . . . . . . . . . . 15
	A.4. Content-Location, Location, and Indirect Responses . . . 16		A.4. Content-Location, Location, and Indirect Responses . . . 16
	A.4.1. Using Content-Location . . . . . . . . . . . . . . . 17		A.4.1. Using Content-Location . . . . . . . . . . . . . . . 17
	A.4.2. Using Location . . . . . . . . . . . . . . . . . . . 18		A.4.2. Using Location . . . . . . . . . . . . . . . . . . . 18
	A.4.3. Indirect Responses . . . . . . . . . . . . . . . . . 18		A.4.3. Indirect Responses . . . . . . . . . . . . . . . . . 18
	A.5. Conditional Requests . . . . . . . . . . . . . . . . . . 19		A.5. Conditional Requests . . . . . . . . . . . . . . . . . . 19
	A.6. More Query Formats . . . . . . . . . . . . . . . . . . . 23		A.6. More Query Formats . . . . . . . . . . . . . . . . . . . 23
	Appendix B. Selection of the Method Name 'QUERY' . . . . . . . . 26		Appendix B. Selection of the Method Name 'QUERY' . . . . . . . . 26
	Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 27		Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 27
	C.1. Since draft-ietf-httpbis-safe-method-w-body-00 . . . . . 27		C.1. Since draft-ietf-httpbis-safe-method-w-body-00 . . . . . 27
	skipping to change at page 3, line 44 ¶		skipping to change at page 3, line 44 ¶
	processed by the target resource.		processed by the target resource.
	A common query pattern is:		A common query pattern is:
	GET /feed?q=foo&limit=10&sort=-published HTTP/1.1		GET /feed?q=foo&limit=10&sort=-published HTTP/1.1
	Host: example.org		Host: example.org
	However, when the data conveyed is too voluminous to be encoded in		However, when the data conveyed is too voluminous to be encoded in
	the request's URI, this pattern becomes problematic:		the request's URI, this pattern becomes problematic:
	o often size limits are not known ahead of time because a request		o size limits often are not known ahead of time because a request
	can pass through many uncoordinated systems (but note that		can pass through many uncoordinated systems (but note that
	Section 4.1 of [HTTP] recommends senders and recipients to support		Section 4.1 of [HTTP] recommends senders and recipients to support
	at least 8000 octets),		at least 8000 octets),
	o expressing certain kinds of data in the target URI is inefficient		o expressing certain kinds of data in the target URI is inefficient
	because of the overhead of encoding that data into a valid URI,		because of the overhead of encoding that data into a valid URI,
	o request URIs are more likely to be logged than request content,		o request URIs are more likely to be logged than request content and
	and may also turn up in bookmarks,		may also turn up in bookmarks,
	o encoding queries directly into the request URI effectively casts		o encoding queries directly into the request URI effectively casts
	every possible combination of query inputs as distinct resources.		every possible combination of query inputs as distinct resources.
	As an alternative to using GET, many implementations make use of the		As an alternative to using GET, many implementations make use of the
	HTTP POST method to perform queries, as illustrated in the example		HTTP POST method to perform queries, as illustrated in the example
	below. In this case, the input to the query operation is passed as		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		the request content as opposed to using the request URI's query
	component.		component.
	A typical use of HTTP POST for requesting a query is:		A typical use of HTTP POST for requesting a query is:
	POST /feed HTTP/1.1		POST /feed HTTP/1.1
	Host: example.org		Host: example.org
	Content-Type: application/x-www-form-urlencoded		Content-Type: application/x-www-form-urlencoded
	q=foo&limit=10&sort=-published		q=foo&limit=10&sort=-published
	In this variation, however, it is not readily apparent -- absent		In this variation, however, it is not readily apparent -- without
	specific knowledge of the resource and server to which the request is		specific knowledge of the resource and server to which the request is
	being sent -- that a safe, idempotent query is being performed.		being sent -- that a safe, idempotent query is being performed.
	The QUERY method provides a solution that spans the gap between the		The QUERY method provides a solution that spans the gap between the
	use of GET and POST, with the example above being expressed as:		use of GET and POST, with the example above being expressed as:
	QUERY /feed HTTP/1.1		QUERY /feed HTTP/1.1
	Host: example.org		Host: example.org
	Content-Type: application/x-www-form-urlencoded		Content-Type: application/x-www-form-urlencoded
	q=foo&limit=10&sort=-published		q=foo&limit=10&sort=-published
	As with POST, the input to the query operation is passed as the		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.		content of the request rather than as part of the request URI.
	Unlike POST, however, the method is explicitly safe and idempotent,		Unlike POST, however, the method is explicitly safe and idempotent,
	allowing functions like caching and automatic retries to operate.		allowing functions like caching and automatic retries to operate.
	Recognizing the design principle that any important resource ought to		Recognizing the design principle that any important resource ought to
	be identified by a URI, this specification describes how a server can		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		assign URIs to both the query itself or to a specific query result,
	later use in a GET request.		for later use in a GET request.
	Summarizing:		Summarizing:
	+----------+-----------------+-----------------+-------------------+		+----------+-----------------+-----------------+-------------------+
	| |GET |QUERY | POST |		| |GET |QUERY | POST |
	+----------+-----------------+-----------------+-------------------+		+----------+-----------------+-----------------+-------------------+
	|Safe |yes |yes | potentially no |		|Safe |yes |yes | potentially no |
	|Idempotent|yes |yes | potentially no |		|Idempotent|yes |yes | potentially no |
	|URI for |yes (by |optional | no |		|URI for |yes (by |optional | no |
	|query |definition) |(Location | |		|query |definition) |(Location | |
	skipping to change at page 5, line 24 ¶		skipping to change at page 5, line 24 ¶
	|query |(Content-Location|(Content-Location| (Content-Location |		|query |(Content-Location|(Content-Location| (Content-Location |
	|result |response field) |response field) | response field) |		|result |response field) |response field) | response field) |
	|Cacheable |yes |yes | yes, but only for |		|Cacheable |yes |yes | yes, but only for |
	| | | | future GET or |		| | | | future GET or |
	| | | | HEAD requests |		| | | | HEAD requests |
	|Content |"no defined |expected | expected |		|Content |"no defined |expected | expected |
	|(body) |semantics" |(semantics per | (semantics per |		|(body) |semantics" |(semantics per | (semantics per |
	| | |target resource) | target resource) |		| | |target resource) | target resource) |
	+----------+-----------------+-----------------+-------------------+		+----------+-----------------+-----------------+-------------------+
	Table 1: Summary of relevant method properties		Table 1: Summary of Relevant Method Properties
	1.1. Terminology		1.1. Terminology
	This document uses terminology defined in Section 3 of [HTTP].		This document uses terminology defined in Section 3 of [HTTP].
	Furthermore, it uses the terms _URI query parameter_ for parameters		Furthermore, it uses the terms _URI query parameter_ for parameters
	in the query component of a URI (Section 4.2.2 of [HTTP]) and _query		in the query component of a URI (Section 4.2.2 of [HTTP]) and _query
	content_ for the request content (Section 6.4 of [HTTP]) of a QUERY		content_ for the request content (Section 6.4 of [HTTP]) of a QUERY
	request.		request.
	1.2. Notational Conventions		1.2. Notational Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. QUERY		2. QUERY Method
	The QUERY method is used to initiate a server-side query. Unlike the		The QUERY method is used to initiate a server-side query. Unlike the
	GET method, which requests a representation of the resource		GET method, which requests a representation of the resource
	identified by the target URI (as defined by Section 7.1 of [HTTP]),		identified by the target URI (as defined by Section 7.1 of [HTTP]),
	the QUERY method is used to ask the target resource to perform a		the QUERY method is used to ask the target resource to perform a
	query operation within the scope of that target resource.		query operation within the scope of that target resource.
	The content of the request and its media type define the query. The		The content of the request and its media type define the query. The
	origin server determines the scope of the operation based on the		origin server determines the scope of the operation based on the
	target resource.		target resource.
	Servers MUST fail the request if the Content-Type request field		Servers MUST fail the request if the Content-Type request field
	([HTTP], Section 8.3) is missing or is inconsistent with the request		([HTTP], Section 8.3) is missing or is inconsistent with the request
	content.		content.
	As for all HTTP methods, the target URI's query part takes part in		As for all HTTP methods, the target URI's query part takes part in
	identifying the resource being queried. Whether and how it directly		identifying the resource being queried. Whether and how it directly
	affects the result of the query is specific to the resource and out		affects the result of the query is specific to the resource and is
	of scope for this specification.		out of scope for this specification.
	QUERY requests are safe with regard to the target resource ([HTTP],		QUERY requests are safe with regard to the target resource ([HTTP],
	Section 9.2.1) -- that is, the client does not request or expect any		Section 9.2.1); that is, the client does not request or expect any
	change to the state of the target resource. This does not prevent		change to the state of the target resource. This does not prevent
	the server from creating additional HTTP resources through which		the server from creating additional HTTP resources through which
	additional information can be retrieved (see Sections 2.3 and 2.4).		additional information can be retrieved (see Sections 2.3 and 2.4).
	Furthermore, QUERY requests are idempotent ([HTTP], Section 9.2.2) --		Furthermore, QUERY requests are idempotent ([HTTP], Section 9.2.2);
	they can be retried or repeated when needed, for instance after a		they can be retried or repeated when needed, for instance, after a
	connection failure.		connection failure.
	As per Section 15.3 of [HTTP], a 2xx (Successful) response code		As per Section 15.3 of [HTTP], a 2xx (Successful) response code
	signals that the request was successfully received, understood, and		signals that the request was successfully received, understood, and
	accepted.		accepted.
	In particular, a 200 (OK) response indicates that the query was		In particular, a 200 (OK) response indicates that the query was
	successfully processed and the results of that processing are		successfully processed and the results of that processing are
	enclosed as the response content.		enclosed as the response content.
	2.1. Media Types and Content Negotiation		2.1. Media Types and Content Negotiation
	The semantics of a QUERY request depends both on the request content		The semantics of a QUERY request depend both on the request content
	and the associated metadata, such as the Media Type ([HTTP],		and the associated metadata, such as the media type ([HTTP],
	Section 8.3.1). In general, any problem with requests where content		Section 8.3.1). In general, any problem with requests where content
	and metadata are inconsistent MUST be rejected with a 4xx (Client		and metadata are inconsistent MUST be rejected with a 4xx (Client
	Error) response ([HTTP], Section 15.5).		Error) response ([HTTP], Section 15.5).
	The list below describes various cases of failures and recommends		The list below describes various cases of failures and recommends
	specific status codes:		specific status codes:
	o A request lacking media type information by definition is		o If a request lacks media type information, it is incorrect by
	incorrect and needs to fail with a 4xx status code such as 400		definition and needs to fail with a 4xx status code such as 400
	(Client Error).		(Client Error).
	o If a media type is specified, but not supported by the resource, a		o If a media type is specified but is not supported by the resource,
	415 (Unsupported Media Type) is appropriate. This specifically		a 415 (Unsupported Media Type) is appropriate. This specifically
	includes the case where the media type is known in principle, but		includes the case where the media type is known in principle, but
	lacks semantics specific to a QUERY to the target resource. In		it lacks semantics specific to a QUERY to the target resource. In
	both cases, the Accept-Query response field (Section 3) can be		both cases, the Accept-Query response field (Section 3) can be
	used to inform the client of media types which are supported.		used to inform the client of the media types that are supported.
	o If a media type is specified, but is inconsistent with the actual		o If a media type is specified but is inconsistent with the actual
	request content, a 400 (Bad Request) can be returned. That is, a		request content, a 400 (Bad Request) can be returned. That is, a
	server is not allowed to infer a media type from the request		server is not allowed to infer a media type from the request
	content and then override a missing or "erroneous" value ("content		content and then override a missing or "erroneous" value (i.e.,
	sniffing").		"content sniffing").
	o If the media type is specified, is understood, and the content is		o If the media type is specified and understood, and the content is
	indeed consistent with the type, but the query cannot be processed		indeed consistent with the type, but the query cannot be processed
	due to the actual contents of the query, the status 422		due to the actual contents of the query, the status 422
	(Unprocessable Content) can be used. An example would be a		(Unprocessable Content) can be used. An example would be a
	syntactically correct SQL query that identifies a non-existent		syntactically correct SQL query that identifies a non-existent
	table.		table.
	o Finally, if the client requests a specific response media type		o If the client requests a specific response media type using the
	using the Accept field ([HTTP], Section 12.5.1) which is not		Accept field ([HTTP], Section 12.5.1) that is not supported by the
	supported by the resource, a status code of 406 (Not Acceptable)		resource, a status code of 406 (Not Acceptable) is appropriate.
	is appropriate.
	2.2. Equivalent Resource		2.2. Equivalent Resource
	The _equivalent resource_ for any given QUERY request is a resource		The _equivalent resource_ for any given QUERY request is a resource
	responding to GET requests, representing that QUERY request and its		that responds to GET requests, represents that QUERY request and its
	target, taking both message content and metadata into account		target, and takes both message content and metadata into account
	(Section 6 of [HTTP]). In particular, this includes representation		(Section 6 of [HTTP]). In particular, this includes representation
	metadata (Section 8 of [HTTP]), such as the content's media type.		metadata (Section 8 of [HTTP]) such as the content's media type.
	In other words, the equivalent resource is derived from the resource		In other words, the equivalent resource is derived from the resource
	implementing QUERY by incorporating the request content.		implementing QUERY by incorporating the request content.
	The term _equivalent resource_ is used as a means to define behavior		The term _equivalent resource_ is used as a means to define behavior
	for other HTTP aspects, such as selected representations. Servers		for other HTTP aspects, such as selected representations. Servers
	can but do not have to assign URIs to these resources (see		can but do not have to assign URIs to these resources (see
	Section 1.1 of [URI]). If they do so, these resources will become		Section 1.1 of [URI]). If they do so, these resources will become
	accessible for GET requests.		accessible for GET requests.
	skipping to change at page 8, line 46 ¶		skipping to change at page 8, line 46 ¶
	A response with either status codes 301 (Moved Permanently, [HTTP],		A response with either status codes 301 (Moved Permanently, [HTTP],
	Section 15.4.2) or 308 (Permanent Redirect, [HTTP], Section 15.4.9)		Section 15.4.2) or 308 (Permanent Redirect, [HTTP], Section 15.4.9)
	indicates that the target resource has permanently moved to a		indicates that the target resource has permanently moved to a
	different URI referenced by the Location response field ([HTTP],		different URI referenced by the Location response field ([HTTP],
	Section 10.2.2). Likewise, a response with either status codes 302		Section 10.2.2). Likewise, a response with either status codes 302
	(Found, [HTTP], Section 15.4.3) or 307 (Temporary Redirect, [HTTP],		(Found, [HTTP], Section 15.4.3) or 307 (Temporary Redirect, [HTTP],
	Section 15.4.8) indicates that the target resource has temporarily		Section 15.4.8) indicates that the target resource has temporarily
	moved. In all four cases, the server is suggesting that the user		moved. In all four cases, the server is suggesting that the user
	agent can accomplish its original QUERY request by sending a similar		agent can accomplish its original QUERY request by sending a similar
	QUERY request to the new target URI referenced by Location.		QUERY request to the new target URI referenced by the Location.
	Note that the exceptions for redirecting a POST as a GET request		Note that the exceptions for redirecting a POST as a GET request
	after a 301 or 302 response do not apply to QUERY requests.		after a 301 or 302 response do not apply to QUERY requests.
	A response to QUERY with the status code 303 (See Other,		A response to QUERY with the status code 303 (See Other,
	Section 15.4.4 of [HTTP]) indicates that the original query can be		Section 15.4.4 of [HTTP]) indicates that the original query can be
	accomplished via a normal retrieval request on the URI referenced by		accomplished via a normal retrieval request on the URI referenced by
	the Location response field ([HTTP], Section 10.2.2). For HTTP, this		the Location response field ([HTTP], Section 10.2.2). For HTTP, this
	means sending a GET request to the new target URI, as illustrated by		means sending a GET request to the new target URI, as illustrated by
	the example in Appendix A.4.3.		the example in Appendix A.4.3.
	2.6. Conditional Requests		2.6. Conditional Requests
	The selected representation (Section 3.2 of [HTTP]) of a QUERY		The selected representation (Section 3.2 of [HTTP]) of a QUERY
	request is the same as for a GET request to the equivalent resource		request is the same as for a GET request to the equivalent resource
	(Section 2.2) of that QUERY request.		(Section 2.2) of that QUERY request.
	A conditional QUERY requests that that selected representation (i.e.,		A conditional QUERY requests that the selected representation (i.e.,
	the query results, after any content negotiation) be returned in the		the query results after any content negotiation) be returned in the
	response only under the circumstances described by the conditional		response only under the circumstances described by the conditional
	header field(s), as defined in Section 13 of [HTTP].		header field(s), as defined in Section 13 of [HTTP].
	See Appendix A.5 for examples.		See Appendix A.5 for examples.
	2.7. Caching		2.7. Caching
	The response to a QUERY method is cacheable; a cache MAY use it to		The response to a QUERY method is cacheable; a cache MAY use it to
	satisfy subsequent QUERY requests as per Section 4 of [HTTP-CACHING].		satisfy subsequent QUERY requests as per Section 4 of [HTTP-CACHING].
	The cache key for a QUERY request (see Section 2 of [HTTP-CACHING])		The cache key for a QUERY request (Section 2 of [HTTP-CACHING]) MUST
	MUST incorporate the request content (Section 6 of [HTTP-CACHING])		incorporate the request content (Section 6 of [HTTP-CACHING]) and
	and related metadata (Section 8 of [HTTP-CACHING]).		related metadata (Section 8 of [HTTP]).
	To improve cache efficiency, caches MAY remove semantically		To improve cache efficiency, caches MAY remove semantically
	insignificant differences first. For instance, by:		insignificant differences from request content and related metadata
			first. For instance, by:
	o removing content encoding(s) (Section 8.4 of [HTTP]).		o removing content encoding(s) (Section 8.4 of [HTTP]).
	o normalizing based upon knowledge of format conventions, as		o normalizing based upon knowledge of format conventions, as
	indicated by any media subtype suffix in the request's Content-		indicated by any media subtype suffix in the request's Content-
	Type field (e.g., "+json", see Section 4.2.8 of [RFC6838]).		Type field (e.g., "+json"; see Section 4.2.8 of [RFC6838]).
	o normalizing based upon knowledge of the semantics of the content		o normalizing based upon knowledge of the semantics of the content
	itself, as indicated by the request's Content-Type field.		itself, as indicated by the request's Content-Type field.
	Note that any such transformation is performed solely for the purpose		Note that any such transformation is performed solely for the purpose
	of generating a cache key; it does not change the request itself.		of generating a cache key; it does not change the request itself.
	Clients can indicate, using the "no-transform" cache directive		Clients can indicate, using the "no-transform" cache directive
	(Section 5.2.1.6 of [HTTP-CACHING]), that they wish that no such		(Section 5.2.1.6 of [HTTP-CACHING]) that they wish that no such
	transformation happens (but note that this directive is just		transformation happens (but note that this directive is just
	advisory).		advisory).
	Note that caching QUERY method responses is inherently more complex		Note that caching QUERY method responses is inherently more complex
	than caching responses to GET, as complete reading of the request's		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		content is needed in order to determine the cache key. If a QUERY
	response supplies a Location response field (Section 2.4) to indicate		response supplies a Location response field (Section 2.4) to indicate
	a URI for an equivalent resource (Section 2.2), clients can switch to		a URI for an equivalent resource (Section 2.2), clients can switch to
	GET for subsequent requests, thereby simplifying processing.		GET for subsequent requests, thereby simplifying processing.
	2.8. Range Requests		2.8. Range Requests
	The semantics of Range Requests for QUERY are identical to those for		The semantics of Range Requests for QUERY are identical to those for
	GET, as defined in Section 14 of [HTTP]. Byte Range requests (the		GET, as defined in Section 14 of [HTTP]. Byte Range Requests (the
	only range unit defined at the time of writing), however, offer		only range unit defined at the time of writing), however, offer
	little value for the results of a QUERY request.		little value for the results of a QUERY request.
	Query formats often define their own way for limiting or paging		Query formats often define their own way of limiting or paging
	through result sets, such as with "FETCH FIRST ... ROWS ONLY" in SQL.		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		It is expected that these built-in features will be used instead of
	HTTP Range Requests.		HTTP Range Requests.
	3. The "Accept-Query" Header Field		3. The Accept-Query Header Field
	The "Accept-Query" response header field can be used by a resource to		The "Accept-Query" response header field can be used by a resource to
	directly signal support for the QUERY method while identifying the		directly signal support for the QUERY method while identifying the
	specific query format media type(s) that may be used.		specific query format media type(s) that may be used.
	Accept-Query contains a list of media ranges (Section 12.5.1 of		Accept-Query contains a list of media ranges (Section 12.5.1 of
	[HTTP]) using "Structured Fields" syntax ([STRUCTURED-FIELDS]).		[HTTP]) using "Structured Fields" syntax [STRUCTURED-FIELDS]. Media
	Media ranges are represented by a List Structured Header Field of		ranges are represented by a List Structured Header Field of either
	either Tokens or Strings, containing the media range value without		Tokens or Strings, containing the media range value without
	parameters.		parameters.
	Media type parameters, if any, are mapped to Structured Field		Media type parameters, if any, are mapped to Structured Field
	Parameters of type String or Token. The choice of Token vs. String		Parameters with the String or Token type. The choice of Token versus
	is semantically insignificant. That is, recipients MAY convert		String is semantically insignificant. That is, recipients MAY
	Tokens to Strings, but MUST NOT process them differently based on the		convert Tokens to Strings, but MUST NOT process them differently
	received type.		based on the received type.
	Media types do not exactly map to Tokens, for instance they allow a		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		leading digit. In cases like these, the String format needs to be
	used.		used.
	The only supported uses of wildcards are "*/*", which matches any		The only supported uses of wildcards are "*/*", which matches any
	type, or "xxxx/*", which matches any subtype of the indicated type.		type, or "xxxx/*", which matches any subtype of the indicated type.
	The order of types listed in the field value is not significant.		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		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		server that shares the same path; in other words, the query component
	is ignored. If requests to the same resource return different		is ignored. If requests to the same resource return different
	Accept-Query values, the most recently received fresh value (per		Accept-Query values, the most recently received fresh value (per
	Section 4.2 of [HTTP-CACHING]) is used.		Section 4.2 of [HTTP-CACHING]) is used.
	Example:		For example:
	Accept-Query: "application/jsonpath", application/sql;charset="UTF-8"		Accept-Query: "application/jsonpath", application/sql;charset="UTF-8"
	Although the syntax for this field appears to be similar to other		Although the syntax for this field appears to be similar to other
	fields, such as "Accept" (Section 12.5.1 of [HTTP]), it is a		fields, such as "Accept" (Section 12.5.1 of [HTTP]), it is a
	Structured Field and thus MUST be processed as specified in Section 4		Structured Field and thus MUST be processed as specified in Section 4
	of [STRUCTURED-FIELDS].		of [STRUCTURED-FIELDS].
	4. Security Considerations		4. Security Considerations
	skipping to change at page 11, line 44 ¶		skipping to change at page 11, line 46 ¶
	field), assigns a URI to that resource, and the request contains		field), assigns a URI to that resource, and the request contains
	sensitive information that cannot be logged, then that URI SHOULD be		sensitive information that cannot be logged, then that URI SHOULD be
	chosen such that it does not include any sensitive portions of the		chosen such that it does not include any sensitive portions of the
	original request content.		original request content.
	Caches that normalize QUERY content incorrectly or in ways that are		Caches that normalize QUERY content incorrectly or in ways that are
	significantly different from how the resource processes the content		significantly different from how the resource processes the content
	can return an incorrect response if normalization results in a false		can return an incorrect response if normalization results in a false
	positive.		positive.
	A QUERY request from user agents implementing CORS (Cross-Origin		A QUERY request from user agents implementing Cross-Origin Resource
	Resource Sharing) will require a "preflight" request, as QUERY does		Sharing (CORS) will require a "preflight" request, as QUERY does not
	not belong to the set of CORS-safelisted methods (see "Methods		belong to the set of CORS-safelisted methods (see [FETCH]).
	(https://fetch.spec.whatwg.org/#methods)" in [FETCH]).
	5. IANA Considerations		5. IANA Considerations
	5.1. Registration of QUERY method
			5.1. Registration of the QUERY Method
	IANA is requested to add the QUERY method to the HTTP Method Registry		IANA is requested to add the QUERY method to the HTTP Method Registry
	at <http://www.iana.org/assignments/http-methods> (see Section 16.3.1		at <http://www.iana.org/assignments/http-methods> (see Section 16.3.1
	of [HTTP]).		of [HTTP]).
	+-------------+------+------------+---------------+		+-------------+------+------------+------------------------+
	| Method Name | Safe | Idempotent | Specification |		| Method Name | Safe | Idempotent | Specification |
	+-------------+------+------------+---------------+		+-------------+------+------------+------------------------+
	| QUERY | Yes | Yes | Section 2 |		| QUERY | yes | yes | Section 2 of RFC 10008 |
	+-------------+------+------------+---------------+		+-------------+------+------------+------------------------+
	Table 2: QUERY Method Definition		Table 2: QUERY Method Definition
	5.2. Registration of Accept-Query field		5.2. Registration of the Accept-Query Field
	IANA is requested to add the Accept-Query field to the HTTP Field		IANA is requested to add the Accept-Query field to the HTTP Field
	Name Registry at <https://www.iana.org/assignments/http-fields> (see		Name Registry at <https://www.iana.org/assignments/http-fields> (see
	Section 16.1.1 of [HTTP]).		Section 16.1.1 of [HTTP]).
	+--------------+-----------+------------+----------------+----------+		+--------------+-----------+------------+----------------+----------+
	| Field Name | Status | Structured | Reference | Comments |		| Field Name | Status | Structured | Reference | Comments |
	| | | Type | | |		| | | Type | | |
	+--------------+-----------+------------+----------------+----------+		+--------------+-----------+------------+----------------+----------+
	| Accept-Query | permanent | List | Section 3 | |		| Accept-Query | permanent | List | Section 3 | |
	skipping to change at page 13, line 15 ¶		skipping to change at page 13, line 15 ¶
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[STRUCTURED-FIELDS]		[STRUCTURED-FIELDS]
	Nottingham, M. and P-H. Kamp, "Structured Field Values for		Nottingham, M. and P. Kamp, "Structured Field Values for
	HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,		HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
	<https://www.rfc-editor.org/info/rfc9651>.		<https://www.rfc-editor.org/info/rfc9651>.
	[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, DOI 10.17487/RFC3986, January 2005,		RFC 3986, DOI 10.17487/RFC3986, January 2005,
	<https://www.rfc-editor.org/info/rfc3986>.		<https://www.rfc-editor.org/info/rfc3986>.
	6.2. Informative References		6.2. Informative References
	[FETCH] WHATWG, "FETCH", <https://fetch.spec.whatwg.org>.		[FETCH] WHATWG, "FETCH", WHATWG Living Standard,
			<https://fetch.spec.whatwg.org>. Commit snapshot:
			<https://fetch.spec.whatwg.org/commit-
			snapshots/3bab31a55154bda73f25b45a23df718616f2f64e/>.
	[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J.		[RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J.
	Whitehead, "Versioning Extensions to WebDAV (Web		Whitehead, "Versioning Extensions to WebDAV (Web
	Distributed Authoring and Versioning)", RFC 3253,		Distributed Authoring and Versioning)", RFC 3253,
	DOI 10.17487/RFC3253, March 2002,		DOI 10.17487/RFC3253, March 2002,
	<https://www.rfc-editor.org/info/rfc3253>.		<https://www.rfc-editor.org/info/rfc3253>.
	[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed		[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed
	Authoring and Versioning (WebDAV)", RFC 4918,		Authoring and Versioning (WebDAV)", RFC 4918,
	DOI 10.17487/RFC4918, June 2007,		DOI 10.17487/RFC4918, June 2007,
	skipping to change at page 14, line 10 ¶		skipping to change at page 14, line 15 ¶
	[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data		[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
	Interchange Format", STD 90, RFC 8259,		Interchange Format", STD 90, RFC 8259,
	DOI 10.17487/RFC8259, December 2017,		DOI 10.17487/RFC8259, December 2017,
	<https://www.rfc-editor.org/info/rfc8259>.		<https://www.rfc-editor.org/info/rfc8259>.
	[RFC9535] Gössner, S., Ed., Normington, G., Ed., and C. Bormann,		[RFC9535] Gössner, S., Ed., Normington, G., Ed., and C. Bormann,
	Ed., "JSONPath: Query Expressions for JSON", RFC 9535,		Ed., "JSONPath: Query Expressions for JSON", RFC 9535,
	DOI 10.17487/RFC9535, February 2024,		DOI 10.17487/RFC9535, February 2024,
	<https://www.rfc-editor.org/info/rfc9535>.		<https://www.rfc-editor.org/info/rfc9535>.
	[URL] WHATWG, "URL", <https://url.spec.whatwg.org>.		[URL] WHATWG, "URL", WHATWG Living Standard,
			<https://url.spec.whatwg.org>. Commit snapshot:
			<https://url.spec.whatwg.org/commit-
			snapshots/52526653e848c5a56598c84aa4bc8ac9025fb66b/>.
	[XSLT] Kay, M., "XSL Transformations (XSLT) Version 3.0", W3C		[XSLT] Kay, M., Ed., "XSL Transformations (XSLT) Version 3.0",
	Recommendation REC-xslt-30-20170608, June 8, 2017,		W3C Recommendation, June 8, 2017,
	<https://www.w3.org/TR/2017/REC-xslt-30-20170608/>.		<https://www.w3.org/TR/2017/REC-xslt-30-20170608/>.
	Latest version available at		Latest version available at
	<https://www.w3.org/TR/xslt-30/>.		<https://www.w3.org/TR/xslt-30/>.
	Appendix A. Examples		Appendix A. Examples
	The examples below are for illustrative purposes only; if one needs		The examples below are for illustrative purposes only; if one needs
	to send queries that are actually this short, it is likely better to		to send queries that are actually this short, it is likely better to
	use GET.		use GET.
	The media type used in most examples is "application/x-www-form-		The media type used in most examples is "application/x-www-form-
	urlencoded" (as used in POST requests from browser user clients,		urlencoded" (as used in POST requests from browser user clients,
	defined in "application/x-www-form-urlencoded		defined in "application/x-www-form-urlencoded
	(https://url.spec.whatwg.org/#application/x-www-form-urlencoded)" in		(https://url.spec.whatwg.org/#application/x-www-form-urlencoded)" in
	[URL]). The Content-Length fields have been omitted for brevity.		[URL]). The Content-Length fields have been omitted for brevity.
	A.1. Simple Query		A.1. Simple Query
	A simple query with a direct response:		Below is a simple query with a direct response:
	QUERY /contacts HTTP/1.1		QUERY /contacts HTTP/1.1
	Host: example.org		Host: example.org
	Content-Type: application/x-www-form-urlencoded		Content-Type: application/x-www-form-urlencoded
	Accept: application/json		Accept: application/json
	select=surname,givenname,email&limit=10&match=%22email=*@example.*%22		select=surname,givenname,email&limit=10&match=%22email=*@example.*%22
	Response:		Response:
	skipping to change at page 15, line 20 ¶		skipping to change at page 15, line 20 ¶
	"givenname": "John",		"givenname": "John",
	"email": "smith@example.org" },		"email": "smith@example.org" },
	{ "surname": "Jones",		{ "surname": "Jones",
	"givenname": "Sally",		"givenname": "Sally",
	"email": "sally.jones@example.com" },		"email": "sally.jones@example.com" },
	{ "surname": "Dubois",		{ "surname": "Dubois",
	"givenname": "Camille",		"givenname": "Camille",
	"email": "camille.dubois@example.net" }		"email": "camille.dubois@example.net" }
	]		]
	A.2. Discovery of QUERY support		A.2. Discovery of QUERY Support
	A simple way to discover support for QUERY is provided by the OPTIONS		A simple way to discover support for QUERY is provided by the OPTIONS
	(Section 9.3.7 of [HTTP]) method:		(Section 9.3.7 of [HTTP]) method:
	OPTIONS /contacts HTTP/1.1		OPTIONS /contacts HTTP/1.1
	Host: example.org		Host: example.org
	Response:		Response:
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Allow: GET, QUERY, OPTIONS, HEAD		Allow: GET, QUERY, OPTIONS, HEAD
	The Allow response field (Section 10.2.1 of [HTTP]) denotes the set		The Allow response field (Section 10.2.1 of [HTTP]) denotes the set
	of supported methods on the specified resource.		of supported methods on the specified resource.
	There are alternatives to the use of OPTIONS. For instance, a QUERY		There are alternatives to the use of OPTIONS. For instance, a QUERY
	request can be tried without prior knowledge of server support. The		request can be tried without prior knowledge of server support. The
	server would then either process the request, or could respond with a		server would then either process the request, or it could respond
	4xx status such as 405 (Method Not Allowed, Section 15.5.6 of		with a 4xx status such as 405 (Method Not Allowed, Section 15.5.6 of
	[HTTP]), including the Allow response field.		[HTTP]), including the Allow response field.
	A.3. Discovery of QUERY Formats		A.3. Discovery of QUERY Formats
	Discovery of supported media types for QUERY is possible via the		The discovery of supported media types for QUERY is possible via the
	Accept-Query (Section 3) response field:		Accept-Query response field (Section 3):
	HEAD /contacts HTTP/1.1		HEAD /contacts HTTP/1.1
	Host: example.org		Host: example.org
	Response:		Response:
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Type: application/xhtml		Content-Type: application/xhtml
	Accept-Query: application/x-www-form-urlencoded, application/sql		Accept-Query: application/x-www-form-urlencoded, application/sql
	Responses to which request methods will contain Accept-Query will		Responses to which request methods will contain Accept-Query will
	depend on the resource being accessed.		depend on the resource being accessed.
	An alternative to checking Accept-Query would be to make a QUERY		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		request, and then -- in case of a 4xx status such as a 415 response
	Media Type, Section 15.5.16 of [HTTP]) response -- to inspect the		(Unsupported Media Type, Section 15.5.16 of [HTTP]) -- to inspect the
	Accept (Section 12.5.1 of [HTTP]) response field:		Accept response field (Section 12.5.1 of [HTTP]):
	HTTP/1.1 415 Unsupported Media Type		HTTP/1.1 415 Unsupported Media Type
	Content-Type: application/xhtml		Content-Type: application/xhtml
	Accept: application/x-www-form-urlencoded, application/sql		Accept: application/x-www-form-urlencoded, application/sql
	A.4. Content-Location, Location, and Indirect Responses		A.4. Content-Location, Location, and Indirect Responses
	As described in Sections 2.3 and 2.4, the Content-Location and		As described in Sections 2.3 and 2.4, the Content-Location and
	Location response fields in success responses (2xx, Section 15.3 of		Location response fields in success responses (2xx, Section 15.3 of
	[HTTP]) provide a way to identify alternate resources that will		[HTTP]) provide a way to identify alternate resources that will
	respond to GET requests, either for the received result of the		respond to GET requests, either for the received result of the
	request, or for future requests to perform the same operation. Going		request or for future requests to perform the same operation. Going
	back to the example from Appendix A.1:		back to the example from Appendix A.1:
	QUERY /contacts HTTP/1.1		QUERY /contacts HTTP/1.1
	Host: example.org		Host: example.org
	Content-Type: application/x-www-form-urlencoded		Content-Type: application/x-www-form-urlencoded
	Accept: application/json		Accept: application/json
	select=surname,givenname,email&limit=10&match=%22email=*@example.*%22		select=surname,givenname,email&limit=10&match=%22email=*@example.*%22
	Response:		Response:
	skipping to change at page 18, line 4 ¶		skipping to change at page 18, line 4 ¶
	{ "surname": "Smith",		{ "surname": "Smith",
	"givenname": "John",		"givenname": "John",
	"email": "smith@example.org" },		"email": "smith@example.org" },
	{ "surname": "Jones",		{ "surname": "Jones",
	"givenname": "Sally",		"givenname": "Sally",
	"email": "sally.jones@example.com" },		"email": "sally.jones@example.com" },
	{ "surname": "Dubois",		{ "surname": "Dubois",
	"givenname": "Camille",		"givenname": "Camille",
	"email": "camille.dubois@example.net" }		"email": "camille.dubois@example.net" }
	]		]
	Note that there's no guarantee that the server will implement this		Note that there is no guarantee that the server will implement this
	resource indefinitely, so, after an error response, the client would		resource indefinitely, so, after an error response, the client would
	need to redo the original QUERY request in order to obtain a new		need to redo the original QUERY request in order to obtain a new
	alternative location.		alternative location.
	A.4.2. Using Location		A.4.2. Using Location
	The Location response field identifies a resource that will respond		The Location response field identifies a resource that will respond
	to GET with a current result for the same process and parameters as		to GET with a current result for the same process and parameters as
	the original QUERY request.		the original QUERY request.
	skipping to change at page 18, line 40 ¶		skipping to change at page 18, line 40 ¶
	{ "surname": "Smith",		{ "surname": "Smith",
	"givenname": "John",		"givenname": "John",
	"email": "smith@example.org" },		"email": "smith@example.org" },
	{ "surname": "Dubois",		{ "surname": "Dubois",
	"givenname": "Camille",		"givenname": "Camille",
	"email": "camille.dubois@example.net" }		"email": "camille.dubois@example.net" }
	]		]
	Assuming that the server still exposes the resource and that there		Assuming that the server still exposes the resource and that there
	was no change in the query result, a subsequent conditional GET		was no change in the query result, a subsequent conditional GET
	request with		request with the following:
	If-None-Match: "42-1"		If-None-Match: "42-1"
	would result in a 304 response (Not Modified, Section 15.4.5 of		would result in a 304 (Not Modified) response (Section 15.4.5 of
	[HTTP]).		[HTTP]).
	A.4.3. Indirect Responses		A.4.3. Indirect Responses
	Servers can send "indirect" responses (Section 2.5) using the status		Servers can send "indirect" responses (Section 2.5) using the status
	code 303 (See Other, Section 15.4.4 of [HTTP]).		code 303 (See Other, Section 15.4.4 of [HTTP]).
	Given the request at the beginning of Appendix A.4, a server might		Given the request at the beginning of Appendix A.4, a server might
	respond with:		respond with:
	skipping to change at page 19, line 23 ¶		skipping to change at page 19, line 23 ¶
	See stored query at "/contacts/stored-queries/42".		See stored query at "/contacts/stored-queries/42".
	This is similar to including Location on a direct response, except		This is similar to including Location on a direct response, except
	that no result for the query is returned. This allows the server to		that no result for the query is returned. This allows the server to
	only generate or reuse an alternative resource. This resource could		only generate or reuse an alternative resource. This resource could
	then be used as shown in Appendix A.4.2.		then be used as shown in Appendix A.4.2.
	A.5. Conditional Requests		A.5. Conditional Requests
	Consider a resource implementing QUERY that supports "application/		Consider a resource implementing QUERY that supports "application/
	sql" and "application/xslt+xml" ([XSLT]) as request media types, and		sql" and "application/xslt+xml" [XSLT] as request media types, and
	which can generate responses as "text/csv". The data set being		which can generate responses as "text/csv". The data set being
	queried contains RFC document information, and the query returns		queried contains RFC document information, and the query returns
	information grouped by decade:		information grouped by decade:
	QUERY /rfc-index.xml HTTP/1.1		QUERY /rfc-index.xml HTTP/1.1
	Host: example.org		Host: example.org
	Date: Sun, 7 Sep 2025, 00:00:00 GMT		Date: Sun, 7 Sep 2025, 00:00:00 GMT
	Content-Type: application/xslt+xml		Content-Type: application/xslt+xml
	Accept: text/csv		Accept: text/csv
	skipping to change at page 20, line 50 ¶		skipping to change at page 20, line 50 ¶
	HTTP/1.1 304 Not Modified		HTTP/1.1 304 Not Modified
	Date: Mon, 8 Sep 2025, 11:00:00 GMT		Date: Mon, 8 Sep 2025, 11:00:00 GMT
	Content-Type: text/csv		Content-Type: text/csv
	Location: /stored-queries/4815162342		Location: /stored-queries/4815162342
	Accept-Query: "application/sql", "application/xslt+xml"		Accept-Query: "application/sql", "application/xslt+xml"
	Last-Modified: Sun, 31 Aug 2025, 08:44:00 GMT		Last-Modified: Sun, 31 Aug 2025, 08:44:00 GMT
	Vary: Accept-Query, Content-Type		Vary: Accept-Query, Content-Type
	As the server identified a URI for the equivalent resource, that		As the server identified a URI for the equivalent resource, that
	resource can be accessed with GET. In particular, this avoids re-		resource can be accessed with GET. In particular, this avoids
	sending the query request's content:		resending the query request's content:
	GET /stored-queries/4815162342 HTTP/1.1		GET /stored-queries/4815162342 HTTP/1.1
	Host: example.org		Host: example.org
	Date: Sun, 21, Sep 2025, 12:08:00 GMT		Date: Sun, 21, Sep 2025, 12:08:00 GMT
	Accept: text/csv		Accept: text/csv
	If-Modified-Since: Sun, 31 Aug 2025, 00:00:00 GMT		If-Modified-Since: Sun, 31 Aug 2025, 00:00:00 GMT
	Here, the state of the data set indeed changed, so new content is		Here, the state of the data set indeed changed, so new content is
	returned:		returned:
	skipping to change at page 22, line 35 ¶		skipping to change at page 22, line 35 ¶
	| |		| |
	| QUERY with content |		| QUERY with content |
	| (conditional on 'foo') |		| (conditional on 'foo') |
	+---------------------------------------->|		+---------------------------------------->|
	| |		| |
	| 200 OK |		| 200 OK |
	| Validator: bar |		| Validator: bar |
	|<----------------------------------------+		|<----------------------------------------+
	| |		| |
	Figure 1: Data Flow with QUERY only		Figure 1: Data Flow with QUERY Only
	Client Resource		Client Resource
	| |		| |
	| QUERY with content | Equivalent Resource		| QUERY with content | Equivalent Resource
	+------------------------------>| (generates /xyz)		+------------------------------>| (generates /xyz)
	| +---------------------------o		| +---------------------------o
	| | |		| | |
	| 200 OK | |		| 200 OK | |
	| Validator: foo | |		| Validator: foo | |
	| Location: /xyz | |		| Location: /xyz | |
	skipping to change at page 23, line 40 ¶		skipping to change at page 23, line 40 ¶
	| |		| |
	| 200 OK |		| 200 OK |
	| Validator: bar |		| Validator: bar |
	|<----------------------------------------------------------+		|<----------------------------------------------------------+
	| |		| |
	Figure 2: Data Flow with GET to Equivalent Resource		Figure 2: Data Flow with GET to Equivalent Resource
	A.6. More Query Formats		A.6. More Query Formats
	The following examples show requests on a JSON-shaped ([RFC8259])		The following examples show requests on a JSON-shaped [RFC8259]
	database of RFC errata.		database of RFC errata.
	The request below uses XSLT to extract errata information summarized		The request below uses eXtensible Stylesheet Language Transformations
	per year and the defined errata types.		(XSLT) to extract errata information summarized per year and the
			defined errata types.
	QUERY /errata.json HTTP/1.1		QUERY /errata.json HTTP/1.1
	Host: example.org		Host: example.org
	Content-Type: application/xslt+xml		Content-Type: application/xslt+xml
	Accept: application/xml, text/csv		Accept: application/xml, text/csv
	<transform xmlns="http://www.w3.org/1999/XSL/Transform"		<transform xmlns="http://www.w3.org/1999/XSL/Transform"
	xmlns:j="http://www.w3.org/2005/xpath-functions"		xmlns:j="http://www.w3.org/2005/xpath-functions"
	version="3.0">		version="3.0">
	skipping to change at page 25, line 40 ¶		skipping to change at page 25, line 40 ¶
	2018, 350, 61, 118, 98, 73		2018, 350, 61, 118, 98, 73
	2019, 335, 47, 131, 94, 63		2019, 335, 47, 131, 94, 63
	2020, 387, 68, 117, 123, 79		2020, 387, 68, 117, 123, 79
	2021, 321, 44, 148, 63, 66		2021, 321, 44, 148, 63, 66
	2022, 358, 37, 198, 40, 83		2022, 358, 37, 198, 40, 83
	2023, 262, 38, 121, 33, 70		2023, 262, 38, 121, 33, 70
	2024, 322, 33, 125, 23, 141		2024, 322, 33, 125, 23, 141
	9999, 1, 0, 0, 1, 0		9999, 1, 0, 0, 1, 0
	Note the Accept-Query response field indicating that another query		Note the Accept-Query response field indicating that another query
	format -- JSONPath ([RFC9535]) -- is supported as well. The request		format, JSONPath [RFC9535], is supported as well. The request below
	below would report the identifiers of all rejected errata submitted		would report the identifiers of all rejected errata submitted since
	since 2024:		2024:
	QUERY /errata.json HTTP/1.1		QUERY /errata.json HTTP/1.1
	Host: example.org		Host: example.org
	Content-Type: application/jsonpath		Content-Type: application/jsonpath
	Accept: application/json		Accept: application/json
	$..[		$..[
	?@.errata_status_code=="Rejected"		?@.errata_status_code=="Rejected"
	&& @.submit_date>"2024"		&& @.submit_date>"2024"
	]		]
	skipping to change at page 26, line 37 ¶		skipping to change at page 26, line 37 ¶
	"RFC9499","RFC9557","RFC2131","RFC2328","RFC9001","RFC3325",		"RFC9499","RFC9557","RFC2131","RFC2328","RFC9001","RFC3325",
	"RFC9438","RFC2526","RFC2985","RFC7643","RFC9132","RFC6376",		"RFC9438","RFC2526","RFC2985","RFC7643","RFC9132","RFC6376",
	"RFC9110","RFC9460","RFC7748","RFC9497","RFC8463","RFC4035",		"RFC9110","RFC9460","RFC7748","RFC9497","RFC8463","RFC4035",
	"RFC7239","RFC9083","RFC9537","RFC9537","RFC9420","RFC9000",		"RFC7239","RFC9083","RFC9537","RFC9537","RFC9420","RFC9000",
	"RFC9656","RFC9110","RFC2324","RFC2549","RFC6797","RFC2549",		"RFC9656","RFC9110","RFC2324","RFC2549","RFC6797","RFC2549",
	"RFC8894"		"RFC8894"
	]		]
	Appendix B. Selection of the Method Name 'QUERY'		Appendix B. Selection of the Method Name 'QUERY'
	The HTTP Method Registry (<http://www.iana.org/assignments/http-		The "Hypertext Transfer Protocol (HTTP) Method Registry"
	methods>) already contains three other methods with the properties		(<http://www.iana.org/assignments/http-methods>) already contains
	"safe" and "idempotent": "PROPFIND" ([RFC4918]), REPORT" ([RFC3253]),		three other methods with the properties "safe" and "idempotent":
	and "SEARCH" ([RFC5323]).		"PROPFIND" [RFC4918], "REPORT" [RFC3253], and "SEARCH" [RFC5323].
	It would have been possible to re-use any of these, updating it in a		It would have been possible to reuse any of these, updating it in a
	way that it matches what this specification defines as the new method		way that it matches what this specification defines as the new method
	"QUERY". Indeed, the early stages of this specification used		"QUERY". Indeed, the early stages of this specification used
	"SEARCH".		"SEARCH".
	The method name "QUERY" ultimately was chosen because:		The method name "QUERY" ultimately was chosen because:
	o The alternatives use a generic media type for the request content		o The alternatives use a generic media type for the request content
	("application/xml"); the semantics of the request depends solely		("application/xml"); the semantics of the request depend solely on
	on the request content.		the request content.
	o Furthermore, they all originate from the WebDAV activity, about		o Furthermore, they all originate from the WebDAV activity, about
	which many have mixed feelings.		which many have mixed feelings.
	o "QUERY" captures the relation with the URI's query component well.		o "QUERY" captures the relation with the URI's query component well.
	Appendix C. Change Log		Appendix C. Change Log
	This section is to be removed before publishing as an RFC.		This section is to be removed before publishing as an RFC.
	skipping to change at page 31, line 51 ¶		skipping to change at page 31, line 51 ¶
	(<https://github.com/httpwg/http-extensions/issues/3332>)		(<https://github.com/httpwg/http-extensions/issues/3332>)
	o IESG review nits (<https://github.com/httpwg/http-extensions/		o IESG review nits (<https://github.com/httpwg/http-extensions/
	issues/3333>)		issues/3333>)
	o Explain relation to SEARCH etc (<https://github.com/httpwg/http-		o Explain relation to SEARCH etc (<https://github.com/httpwg/http-
	extensions/issues/3337>)		extensions/issues/3337>)
	Acknowledgements		Acknowledgements
	We thank all members of the HTTP Working Group for ideas, reviews,		We thank all members of the HTTP Working Group for their ideas,
	and feedback.		reviews, and feedback.
	The following individuals deserve special recognition: Carsten		The following individuals deserve special recognition: Carsten
	Bormann, Mark Nottingham, Martin Thomson, Michael Thornburgh, Roberto		Bormann, Mark Nottingham, Martin Thomson, Michael Thornburgh, Roberto
	Polli, Roy Fielding, and Will Hawkins.		Polli, Roy Fielding, and Will Hawkins.
	Contributors		Contributors
	Ashok Malhotra participated in early discussions leading to this		Ashok Malhotra participated in early discussions leading to this
	specification:		specification:
	Ashok Malhotra		Ashok Malhotra
	Email: malhotrasahib@gmail.com		Email: malhotrasahib@gmail.com
	Discussion on the this HTTP method was reopened by Asbjørn Ulsberg		Discussion on this HTTP method was reopened by Asbjørn Ulsberg during
	during the HTTP Workshop in 2019:		the HTTP Workshop in 2019:
	Asbjørn Ulsberg		Asbjørn Ulsberg
	Email: asbjorn@ulsberg.no		Email: asbjorn@ulsberg.no
	URI: https://asbjor.nu/		URI: https://asbjor.nu/
	Authors' Addresses		Authors' Addresses
	Julian Reschke		Julian Reschke
	greenbytes GmbH		greenbytes GmbH
	Hafenweg 16		Hafenweg 16
End of changes. 74 change blocks.
	121 lines changed or deleted		128 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/