draft-ietf-httpbis-safe-method-w-body-11.txt		draft-ietf-httpbis-safe-method-w-body-latest.txt
	HTTP Working Group J. Reschke		HTTP 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: November 20, 2025 Cloudflare		Expires: February 10, 2026 Cloudflare
	M. Bishop		M. Bishop
	Akamai		Akamai
	May 19, 2025		August 9, 2025
	The HTTP QUERY Method		The HTTP QUERY Method
	draft-ietf-httpbis-safe-method-w-body-11		draft-ietf-httpbis-safe-method-w-body-latest
	Abstract		Abstract
	This specification defines a new HTTP method, QUERY, as a safe,		This specification defines the QUERY method for HTTP. A QUERY
	idempotent request method that can carry request content.		requests that the request target process the enclosed content in a
			safe/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.
	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/>;
	source code and issues list for this draft can be found at		source code and issues list for this draft can be found at
	<https://github.com/httpwg/http-extensions/labels/query-method>.		<https://github.com/httpwg/http-extensions/labels/query-method>.
	The changes in this draft are summarized in Appendix B.11.		The changes in this draft are summarized in Appendix B.12.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 November 20, 2025.		This Internet-Draft will expire on February 10, 2026.
	Copyright Notice		Copyright Notice
	Copyright (c) 2025 IETF Trust and the persons identified as the		Copyright (c) 2025 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 . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	1.2. Notational Conventions . . . . . . . . . . . . . . . . . 5		1.2. Notational Conventions . . . . . . . . . . . . . . . . . 5
	2. QUERY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. QUERY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Content-Location and Location Fields . . . . . . . . . . 6		2.1. Content-Location Response Field . . . . . . . . . . . . . 6
	2.2. Redirection . . . . . . . . . . . . . . . . . . . . . . . 6		2.2. Location Response Field . . . . . . . . . . . . . . . . . 6
	2.3. Conditional Requests . . . . . . . . . . . . . . . . . . 6		2.3. Redirection . . . . . . . . . . . . . . . . . . . . . . . 7
	2.4. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 7		2.4. Conditional Requests . . . . . . . . . . . . . . . . . . 7
	2.5. Range Requests . . . . . . . . . . . . . . . . . . . . . 7		2.5. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3. The "Accept-Query" Header Field . . . . . . . . . . . . . . . 7		2.6. Range Requests . . . . . . . . . . . . . . . . . . . . . 8
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 8		3. The "Accept-Query" Header Field . . . . . . . . . . . . . . . 8
			4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	5.1. Registration of QUERY method . . . . . . . . . . . . . . 9		5.1. Registration of QUERY method . . . . . . . . . . . . . . 10
	5.2. Registration of Accept-Query field . . . . . . . . . . . 9		5.2. Registration of Accept-Query field . . . . . . . . . . . 10
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	6.1. Normative References . . . . . . . . . . . . . . . . . . 9		6.1. Normative References . . . . . . . . . . . . . . . . . . 10
	6.2. Informative References . . . . . . . . . . . . . . . . . 10		6.2. Informative References . . . . . . . . . . . . . . . . . 11
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11
	A.1. Simple Query . . . . . . . . . . . . . . . . . . . . . . 11		A.1. Simple Query . . . . . . . . . . . . . . . . . . . . . . 12
	A.2. Discovery of QUERY support . . . . . . . . . . . . . . . 11		A.2. Discovery of QUERY support . . . . . . . . . . . . . . . 12
	A.3. Discovery of QUERY Formats . . . . . . . . . . . . . . . 12		A.3. Discovery of QUERY Formats . . . . . . . . . . . . . . . 13
	A.4. Content-Location, Location, and Indirect Responses . . . 12		A.4. Content-Location, Location, and Indirect Responses . . . 13
	A.4.1. Using Content-Location . . . . . . . . . . . . . . . 13		A.4.1. Using Content-Location . . . . . . . . . . . . . . . 14
	A.4.2. Using Location . . . . . . . . . . . . . . . . . . . 14		A.4.2. Using Location . . . . . . . . . . . . . . . . . . . 15
	A.4.3. Indirect Responses . . . . . . . . . . . . . . . . . 15		A.4.3. Indirect Responses . . . . . . . . . . . . . . . . . 16
	A.5. More Query Formats . . . . . . . . . . . . . . . . . . . 15		A.5. More Query Formats . . . . . . . . . . . . . . . . . . . 16
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18		Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20
	B.1. Since draft-ietf-httpbis-safe-method-w-body-00 . . . . . 18		B.1. Since draft-ietf-httpbis-safe-method-w-body-00 . . . . . 20
	B.2. Since draft-ietf-httpbis-safe-method-w-body-01 . . . . . 19		B.2. Since draft-ietf-httpbis-safe-method-w-body-01 . . . . . 21
	B.3. Since draft-ietf-httpbis-safe-method-w-body-02 . . . . . 19		B.3. Since draft-ietf-httpbis-safe-method-w-body-02 . . . . . 21
	B.4. Since draft-ietf-httpbis-safe-method-w-body-03 . . . . . 19		B.4. Since draft-ietf-httpbis-safe-method-w-body-03 . . . . . 21
	B.5. Since draft-ietf-httpbis-safe-method-w-body-04 . . . . . 19		B.5. Since draft-ietf-httpbis-safe-method-w-body-04 . . . . . 21
	B.6. Since draft-ietf-httpbis-safe-method-w-body-05 . . . . . 19		B.6. Since draft-ietf-httpbis-safe-method-w-body-05 . . . . . 21
	B.7. Since draft-ietf-httpbis-safe-method-w-body-06 . . . . . 20		B.7. Since draft-ietf-httpbis-safe-method-w-body-06 . . . . . 22
	B.8. Since draft-ietf-httpbis-safe-method-w-body-07 . . . . . 21		B.8. Since draft-ietf-httpbis-safe-method-w-body-07 . . . . . 23
	B.9. Since draft-ietf-httpbis-safe-method-w-body-08 . . . . . 21		B.9. Since draft-ietf-httpbis-safe-method-w-body-08 . . . . . 23
	B.10. Since draft-ietf-httpbis-safe-method-w-body-09 . . . . . 21		B.10. Since draft-ietf-httpbis-safe-method-w-body-09 . . . . . 23
	B.11. Since draft-ietf-httpbis-safe-method-w-body-10 . . . . . 21		B.11. Since draft-ietf-httpbis-safe-method-w-body-10 . . . . . 23
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22		B.12. Since draft-ietf-httpbis-safe-method-w-body-11 . . . . . 24
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 22		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22		Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
	1. Introduction		1. Introduction
	This specification defines the HTTP QUERY request method as a means		This specification defines the HTTP QUERY request method as a means
	of making a safe, idempotent request (Section 9.2 of [HTTP]) that		of making a safe, idempotent request (Section 9.2 of [HTTP])
	contains content.		containing content that describes how the request is to be processed
			by the target resource.
	Most often, this is desirable when the data conveyed in a request is		Most often, this is desirable when the data conveyed in a request is
	too voluminous to be encoded into the request's URI. For example,		too voluminous to be encoded into the request's URI. A common query
	this is a common query pattern:		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, for a query with parameters that are complex or large,		However, when the data conveyed is too voluminous to be encoded in
	encoding it in the request URI may not be the best option because		the request's URI, this pattern becomes problematic:
	o often size limits are not known ahead of time because a request		o often size limits 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,
	and
			o request URIs are more likely to be logged than request content,
			and 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
	This variation, however, suffers from the same basic limitation as		This variation, however, suffers from the fact that it is not readily
	GET in that it is not readily apparent -- absent specific knowledge		apparent -- absent specific knowledge of the resource and server to
	of the resource and server to which the request is being sent -- that		which the request is being sent -- that a safe, idempotent query is
	a safe, idempotent query is being performed.		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
			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:		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 |
	| Cacheable | yes | yes | yes, but only |		|URI for |yes (by |optional | no |
	| | | | for future GET |		|query |definition) |(Location | |
	| | | | or HEAD requests |		|itself | |response field) | |
	| Content | "no | expected | expected |		|URI for |optional |optional | optional |
	| (body) | defined | (semantics per | (semantics per |		|query |(Content-Location|(Content-Location| (Content-Location |
	| | semantics" | target resource) | target resource) |		|result |response field) |response field) | response field) |
	+------------+------------+------------------+------------------+		|Cacheable |yes |yes | yes, but only for |
			| | | | future GET or |
			| | | | HEAD requests |
			|Content |"no defined |expected | expected |
			|(body) |semantics" |(semantics per | (semantics per |
			| | |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.
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 29 ¶
	computing and memory resources or even create additional HTTP		computing and memory resources or even create additional HTTP
	resources through which the response can be retrieved.		resources through which the response can be retrieved.
	A successful response to a QUERY request is expected to provide some		A successful response to a QUERY request is expected to provide some
	indication as to the final disposition of the operation. For		indication as to the final disposition of the operation. For
	instance, a successful query that yields no results can be		instance, a successful query that yields no results can be
	represented by a 204 (No Content, Section 15.3.5 of [HTTP]) response.		represented by a 204 (No Content, Section 15.3.5 of [HTTP]) response.
	If the response includes content, it is expected to describe the		If the response includes content, it is expected to describe the
	results of the operation.		results of the operation.
	2.1. Content-Location and Location Fields		2.1. Content-Location Response Field
	A successful response (2xx, Section 15.3 of [HTTP]) can include a		A successful response (2xx, Section 15.3 of [HTTP]) can include a
	Content-Location header field containing an identifier for a resource		Content-Location header field containing an identifier for a resource
	corresponding to the results of the operation; see Section 8.7 of		corresponding to the results of the operation; see Section 8.7 of
	[HTTP] for details. This represents a claim from the server that a		[HTTP] for details. This represents a claim from the server that a
	client can send a GET request for the indicated URI to retrieve the		client can send a GET request for the indicated URI to retrieve the
	results of the query operation just performed. The indicated		results of the query operation just performed. The indicated
	resource might be temporary.		resource might be temporary.
			See Appendix A.4.1 for an example.
			2.2. Location Response Field
	A server can create or locate a resource that identifies the query		A server can create or locate a resource that identifies the query
	operation for future use. If the server does so, the URI of the		operation for future use. If the server does so, the URI of the
	resource can be included in the Location header field of the 2xx		resource can be included in the Location header field of the 2xx
	response (see Section 10.2.2 of [HTTP]). This represents a claim		response (see Section 10.2.2 of [HTTP]). This represents a claim
	that a client can send a GET request to the indicated URI to repeat		that a client can send a GET request to the indicated URI to repeat
	the query operation just performed without resending the query		the query operation just performed without resending the query
	content. This resource might be temporary; if a future request		content. This resource might be temporary; if a future request
	fails, the client can retry using the original QUERY resource and the		fails, the client can retry using the original QUERY resource and the
	previously submitted content.		previously submitted content.
	2.2. Redirection		See Appendix A.4.2 for an example.
			2.3. Redirection
	In some cases, the server may choose to respond indirectly to the		In some cases, the server may choose to respond indirectly to the
	QUERY request by redirecting the user agent to a different URI (see		QUERY request by redirecting the user agent to a different URI (see
	Section 15.4 of [HTTP]). The semantics of the redirect response do		Section 15.4 of [HTTP]).
	not differ from other methods.
	For instance, a 303 (See Other, Section 15.4.4 of [HTTP]) response		A response with either of the status codes 301 (Moved Permanently,
	would indicate that the Location field identifies an alternate URI		Section 15.4.2 of [HTTP]) or 308 (Permanent Redirect, Section 15.4.9
	from which the results can be retrieved using a GET request (this use		of [HTTP]) indicates that the target resource has permanently moved
	case is also covered by the use of the Location response field in a		to a different URI referenced by the Location response field ([HTTP],
	2xx response).		Section 10.2.2). Likewise, a response with either 302 (Found,
			Section 15.4.3 of [HTTP] or 307 (Temporary Redirect, Section 15.4.8
			of [HTTP]) 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.
	On the other hand, response codes 307 (Temporary Redirect,		Note that the exceptions for redirecting a POST as a GET request
	Section 15.4.8 of [HTTP]) and 308 (Permanent Redirect, Section 15.4.9		after a 301 or 302 response do not apply to QUERY requests.
	of [HTTP]) can be used to request the user agent to redo the QUERY
	request on the URI specified by the Location field.
	Various non-normative examples of successful QUERY responses are		A response to QUERY with the status code 303 (See Other,
	illustrated in Appendix A.		Section 15.4.4 of [HTTP]) indicates that the original query can be
			accomplished via a normal retrieval request on the URI referenced by
			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
			the example in Appendix A.4.3.
	2.3. Conditional Requests		2.4. Conditional Requests
	A conditional QUERY requests that the 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].
	2.4. Caching		2.5. 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		satisfy subsequent QUERY requests as per Section 4 of
	[HTTP-CACHING]).		[HTTP-CACHING]).
	The cache key for a QUERY request (see Section 2 of [HTTP-CACHING])		The cache key for a QUERY request (see Section 2 of [HTTP-CACHING])
	MUST incorporate the request content. When doing so, caches SHOULD		MUST incorporate the request content.
	first normalize request content to remove semantically insignificant
	differences, thereby improving cache efficiency, by:
	o Removing content encoding(s) (Section 8.4 of [HTTP]).		Caches MAY remove semantically insignificant differences first,
			thereby improving cache efficiency.
	o Normalizing based upon knowledge of format conventions, as		For instance, by
			o removing content encoding(s) (Section 8.4 of [HTTP]).
			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 normalization 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.
	2.5. Range Requests		Clients can indicate, using the "no-transform" cache directive
			(Section 5.2.1.6 of [HTTP-CACHING]), that they wish that no such
			transformation happens (but note that this directive is just
			advisory).
			2.6. 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].		GET, as defined in Section 14 of [HTTP].
	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.
	skipping to change at page 9, line 11 ¶		skipping to change at page 10, line 4 ¶
	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 CORS (Cross-Origin
	Resource Sharing) will require a "preflight" request, as QUERY does		Resource Sharing) will require a "preflight" request, as QUERY does
	not belong to the set of CORS-safelisted methods (see "Methods		not belong to the set of CORS-safelisted methods (see "Methods
	(https://fetch.spec.whatwg.org/#methods)" in [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 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 |
	+-------------+------+------------+---------------+		+-------------+------+------------+---------------+
	Table 2		Table 2: QUERY Method Definition
	5.2. Registration of Accept-Query field		5.2. Registration of 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 | |
	| | | | of this | |		| | | | of this | |
	| | | | document. | |		| | | | document. | |
	+--------------+-----------+------------+----------------+----------+		+--------------+-----------+------------+----------------+----------+
	Table 3		Table 3: Accept-Query Field Definition
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "HTTP Semantics", STD 97, RFC 9110,		Ed., "HTTP Semantics", STD 97, RFC 9110,
	DOI 10.17487/RFC9110, June 2022,		DOI 10.17487/RFC9110, June 2022,
	<https://www.rfc-editor.org/info/rfc9110>.		<https://www.rfc-editor.org/info/rfc9110>.
	skipping to change at page 12, line 46 ¶		skipping to change at page 13, line 41 ¶
	request, and then -- in case of a 4xx status such as 415 (Unsupported		request, and then -- in case of a 4xx status such as 415 (Unsupported
	Media Type, Section 15.5.16 of [HTTP]) response -- to inspect the		Media Type, Section 15.5.16 of [HTTP]) response -- to inspect the
	Accept (Section 12.5.1 of [HTTP]) response field:		Accept (Section 12.5.1 of [HTTP]) response field:
	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 Section 2.1, the Content-Location and Location		As described in Sections 2.1 and 2.2, the Content-Location and
	response fields in success responses (2xx, Section 15.3 of [HTTP])		Location response fields in success responses (2xx, Section 15.3 of
	provide a way to identify alternate resources that will respond to		[HTTP]) provide a way to identify alternate resources that will
	GET requests, either for the received result of the request, or for		respond to GET requests, either for the received result of the
	future requests to perform the same operation. Going back to the		request, or for future requests to perform the same operation. Going
	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 14, line 21 ¶		skipping to change at page 15, line 21 ¶
	"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
			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.
	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 fresh result for the QUERY response it appeared on.		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		GET /contacts/stored-queries/42 HTTP/1.1
	Host: example.org		Host: example.org
	Accept: application/json		Accept: application/json
	In this example, one entry was removed at 2024-11-17T16:12:01Z (as		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		indicated in the Last-Modified field), so the response only contains
	two entries:		two entries:
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	skipping to change at page 14, line 49 ¶		skipping to change at page 16, line 20 ¶
	[		[
	{ "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 no change in the query result, a subsequent conditional GET		Assuming that the server still exposes the resource and that there
			was no change in the query result, a subsequent conditional GET
	request with		request with
	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 response (Not Modified, Section 15.4.5 of
	[HTTP]).		[HTTP]).
	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.
	A.4.3. Indirect Responses		A.4.3. Indirect Responses
	Servers can send "indirect" responses (Section 2.2) using the status		Servers can send "indirect" responses (Section 2.3) 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:
	HTTP/1.1 303 See Other		HTTP/1.1 303 See Other
	Content-Type: text/plain		Content-Type: text/plain
	Date: Sun, 17 Nov 2024, 16:13:17 GMT		Date: Sun, 17 Nov 2024, 16:13:17 GMT
	Location: /contacts/stored-queries/42		Location: /contacts/stored-queries/42
	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 an alternative resource. This resource could then be		only generate or reuse an alternative resource. This resource could
	used as shown in Appendix A.4.2.		then be used as shown in Appendix A.4.2.
	A.5. More Query Formats		A.5. 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 ([XSLT]) to extract errata information		The request below uses XSLT ([XSLT]) to extract errata information
	summarized per year and the defined errata types.		summarized per year and the defined errata types.
	QUERY /errata.json HTTP/1.1		QUERY /errata.json HTTP/1.1
	skipping to change at page 22, line 17 ¶		skipping to change at page 24, line 17 ¶
	o Update James' affiliation (<https://github.com/httpwg/http-		o Update James' affiliation (<https://github.com/httpwg/http-
	extensions/pull/3094>)		extensions/pull/3094>)
	o Review references to HTTP (<https://github.com/httpwg/http-		o Review references to HTTP (<https://github.com/httpwg/http-
	extensions/pull/3097>)		extensions/pull/3097>)
	o Address most Rahul Gupta's additional feedback		o Address most Rahul Gupta's additional feedback
	(<https://github.com/httpwg/http-extensions/pull/3101>)		(<https://github.com/httpwg/http-extensions/pull/3101>)
			B.12. Since draft-ietf-httpbis-safe-method-w-body-11
			o Improve description of caching, clarifying what is required
			(<https://github.com/httpwg/http-extensions/tree/reschke-3107>)
			o Address HTTPDIR/RF feedback on example appendix
			(<https://github.com/httpwg/http-extensions/issues/3114>)
			o Address HTTPDIR/RF feedback on redirection
			(<https://github.com/httpwg/http-extensions/issues/3119>)
			o Address HTTPDIR/RF feedback on abstract
			(<https://github.com/httpwg/http-extensions/issues/3121>)
			o Address HTTPDIR/RF feedback on introduction
			(<https://github.com/httpwg/http-extensions/issues/3122>)
			o Consistent Table Captions (<https://github.com/httpwg/http-
			extensions/issues/3134>)
	Acknowledgements		Acknowledgements
	We thank all members of the HTTP Working Group for ideas, reviews,		We thank all members of the HTTP Working Group for ideas, reviews,
	and feedback.		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
End of changes. 45 change blocks.
	111 lines changed or deleted		173 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/