draft-ietf-httpbis-safe-method-w-body-08.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 A. Malhotra		Intended status: Standards Track J.M. Snell
	Expires: August 29, 2025		Expires: September 22, 2025
	J.M. Snell
	M. Bishop		M. Bishop
	Akamai		Akamai
	February 25, 2025		March 21, 2025
	The HTTP QUERY Method		The HTTP QUERY Method
	draft-ietf-httpbis-safe-method-w-body-08		draft-ietf-httpbis-safe-method-w-body-latest
	Abstract		Abstract
	This specification defines a new HTTP method, QUERY, as a safe,		This specification defines a new HTTP method, QUERY, as a safe,
	idempotent request method that can carry request content.		idempotent request method that can carry request content.
	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.8.		The changes in this draft are summarized in Appendix B.9.
	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 August 29, 2025.
			This Internet-Draft will expire on September 22, 2025.
	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
	skipping to change at page 2, line 41 ¶		skipping to change at page 2, line 40 ¶
	3. The "Accept-Query" Header Field . . . . . . . . . . . . . . . 7		3. The "Accept-Query" Header Field . . . . . . . . . . . . . . . 7
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 8		4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	5.1. Registration of QUERY method . . . . . . . . . . . . . . 8		5.1. Registration of QUERY method . . . . . . . . . . . . . . 8
	5.2. Registration of Accept-Query field . . . . . . . . . . . 8		5.2. Registration of Accept-Query field . . . . . . . . . . . 8
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	6.1. Normative References . . . . . . . . . . . . . . . . . . 9		6.1. Normative References . . . . . . . . . . . . . . . . . . 9
	6.2. Informative References . . . . . . . . . . . . . . . . . 9		6.2. Informative References . . . . . . . . . . . . . . . . . 9
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 10		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 10
	A.1. Simple Query . . . . . . . . . . . . . . . . . . . . . . 10		A.1. Simple Query . . . . . . . . . . . . . . . . . . . . . . 10
	A.2. Discovery of QUERY support . . . . . . . . . . . . . . . 10		A.2. Discovery of QUERY support . . . . . . . . . . . . . . . 11
	A.3. Discovery of QUERY Formats . . . . . . . . . . . . . . . 11		A.3. Discovery of QUERY Formats . . . . . . . . . . . . . . . 11
	A.4. Content-Location, Location, and Indirect Responses . . . 12		A.4. Content-Location, Location, and Indirect Responses . . . 12
	A.4.1. Using Content-Location . . . . . . . . . . . . . . . 12		A.4.1. Using Content-Location . . . . . . . . . . . . . . . 13
	A.4.2. Using Location . . . . . . . . . . . . . . . . . . . 13		A.4.2. Using Location . . . . . . . . . . . . . . . . . . . 14
	A.4.3. Indirect Responses . . . . . . . . . . . . . . . . . 14		A.4.3. Indirect Responses . . . . . . . . . . . . . . . . . 14
	A.5. More Query Formats . . . . . . . . . . . . . . . . . . . 14		A.5. More Query Formats . . . . . . . . . . . . . . . . . . . 15
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 17		Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18
	B.1. Since draft-ietf-httpbis-safe-method-w-body-00 . . . . . 17		B.1. Since draft-ietf-httpbis-safe-method-w-body-00 . . . . . 18
	B.2. Since draft-ietf-httpbis-safe-method-w-body-01 . . . . . 18		B.2. Since draft-ietf-httpbis-safe-method-w-body-01 . . . . . 19
	B.3. Since draft-ietf-httpbis-safe-method-w-body-02 . . . . . 18		B.3. Since draft-ietf-httpbis-safe-method-w-body-02 . . . . . 19
	B.4. Since draft-ietf-httpbis-safe-method-w-body-03 . . . . . 18		B.4. Since draft-ietf-httpbis-safe-method-w-body-03 . . . . . 19
	B.5. Since draft-ietf-httpbis-safe-method-w-body-04 . . . . . 18		B.5. Since draft-ietf-httpbis-safe-method-w-body-04 . . . . . 19
	B.6. Since draft-ietf-httpbis-safe-method-w-body-05 . . . . . 18		B.6. Since draft-ietf-httpbis-safe-method-w-body-05 . . . . . 19
	B.7. Since draft-ietf-httpbis-safe-method-w-body-06 . . . . . 19		B.7. Since draft-ietf-httpbis-safe-method-w-body-06 . . . . . 20
	B.8. Since draft-ietf-httpbis-safe-method-w-body-07 . . . . . 20		B.8. Since draft-ietf-httpbis-safe-method-w-body-07 . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		B.9. Since draft-ietf-httpbis-safe-method-w-body-08 . . . . . 21
			Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
			Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 21
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
	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 that contains content.		of making a safe, idempotent request that contains content.
	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. For example,
	this is a common query pattern:		this is a common query pattern:
	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, for a query with parameters that are complex or large,
	encoding it in the request URI may not be the best option because		encoding it in the request URI may not be the best option because
	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 system (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		and
	o encoding query parameters directly into the request URI		o encoding queries directly into the request URI effectively casts
	effectively casts every possible combination of query inputs as		every possible combination of query inputs as distinct resources.
	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 parameters to the query operation are		below. In this case, the input parameters to the query operation are
	passed along within the request content as opposed to using the		passed along within the request content as opposed to using the
	request URI.		request URI.
	A typical use of HTTP POST for requesting a query:		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 same basic limitation as
	GET in that it is not readily apparent -- absent specific knowledge		GET in that it is not readily apparent -- absent specific knowledge
	of the resource and server to which the request is being sent -- that		of the resource and server to which the request is being sent -- that
	a safe, idempotent query is being performed.		a safe, idempotent query is being performed.
	skipping to change at page 5, line 20 ¶		skipping to change at page 5, line 20 ¶
	Section 7.1 of [HTTP]), the QUERY method is used to ask the server to		Section 7.1 of [HTTP]), the QUERY method is used to ask the server to
	perform a query operation (described by the request content) over		perform a query operation (described by the request content) over
	some set of data scoped to the target URI. The content returned in		some set of data scoped to the target URI. The content returned in
	response to a QUERY cannot be assumed to be a representation of the		response to a QUERY cannot be assumed to be a representation of the
	resource identified by the target URI.		resource identified by the target URI.
	The content of the request defines the query. Implementations MAY		The content of the request defines the query. Implementations MAY
	use a request content of any media type with the QUERY method,		use a request content of any media type with the QUERY method,
	provided that it has appropriate query semantics.		provided that it has appropriate query semantics.
	QUERY requests are both safe and idempotent with regards to the		QUERY requests are both safe and idempotent with regard to the
	resource identified by the request URI. That is, QUERY requests do		resource identified by the request URI. That is, QUERY requests do
	not alter the state of the targeted resource. However, while		not alter the state of the targeted resource. However, while
	processing a QUERY request, a server can be expected to allocate		processing a QUERY request, a server can be expected to allocate
	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 response. If the response includes		represented by a 204 (No Content) response. If the response includes
	content, it is expected to describe the results of the operation.		content, it is expected to describe the results of the operation.
	2.1. Content-Location and Location Fields		2.1. Content-Location and Location Fields
	Furthermore, a successful response can include a Content-Location		Furthermore, a successful response can include a Content-Location
	header field (see Section 8.7 of [HTTP]) containing an identifier for		header field (see Section 8.7 of [HTTP]) containing an identifier for
	a resource corresponding to the results of the operation. This		a resource corresponding to the results of the operation. This
	represents a claim from the server that a client can send a GET		represents a claim from the server that a client can send a GET
	request for the indicated URI to retrieve the results of the query		request for the indicated URI to retrieve the results of the query
	operation just performed. The indicated resource might be temporary.		operation just performed. The indicated resource might be temporary.
	A server MAY 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 response		resource can be included in the Location header field of the response
	(see Section 10.2.2 of [HTTP]). This represents a claim that a		(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 the		client can send a GET request to the indicated URI to repeat the
	query operation just performed without resending the query		query operation just performed without resending the query payload.
	parameters. This resource might be temporary; if a future request		This resource might be temporary; if a future request fails, the
	fails, the client can retry using the original QUERY resource and the		client can retry using the original QUERY resource and the previously
	previously submitted parameters again.		submitted payload.
	2.2. Redirection		2.2. 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]). The semantics of the redirect response do
	not differ from other methods. For instance, a 303 (See Other)		not differ from other methods. For instance, a 303 (See Other)
	response would indicate that the Location field identifies an		response would indicate that the Location field identifies an
	alternate URI from which the results can be retrieved using a GET		alternate URI from which the results can be retrieved using a GET
	request (this use case is also covered by the use of the Location		request (this use case is also covered by the use of the Location
	skipping to change at page 6, line 38 ¶		skipping to change at page 6, line 38 ¶
	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 (see Section 2 of [HTTP-CACHING]) MUST		The cache key for a query (see Section 2 of [HTTP-CACHING]) MUST
	incorporate the request content. When doing so, caches SHOULD first		incorporate the request content. When doing so, caches SHOULD first
	normalize request content to remove semantically insignificant		normalize request content to remove semantically insignificant
	differences, thereby improving cache efficiency, by:		differences, thereby improving cache efficiency, by:
	o Removing content encoding(s)		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 type suffix in the request's Content-Type		indicated by any media subtype suffix in the request's Content-
	field (e.g., "+json")		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 normalization 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		2.5. 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
	skipping to change at page 8, line 13 ¶		skipping to change at page 8, line 13 ¶
	of [STRUCTURED-FIELDS].		of [STRUCTURED-FIELDS].
	4. Security Considerations		4. Security Considerations
	The QUERY method is subject to the same general security		The QUERY method is subject to the same general security
	considerations as all HTTP methods as described in [HTTP].		considerations as all HTTP methods as described in [HTTP].
	It can be used as an alternative to passing request information in		It can be used as an alternative to passing request information in
	the URI (e.g., in the query section). This is preferred in some		the URI (e.g., in the query section). This is preferred in some
	cases, as the URI is more likely to be logged or otherwise processed		cases, as the URI is more likely to be logged or otherwise processed
	by intermediaries than the request content. If a server creates a		by intermediaries than the request content.
	temporary resource to represent the results of a QUERY request (e.g.,
	for use in the Location or Content-Location field) and the request		If a server creates a temporary resource to represent the results of
	contains sensitive information that cannot be logged, then the URI of		a QUERY request (e.g., for use in the Location or Content-Location
	this resource SHOULD be chosen such that it does not include any		field) and the request contains sensitive information that cannot be
	sensitive portions of the original request content.		logged, then the URI of this resource SHOULD be chosen such that it
			does not include any sensitive portions of the original request
			content.
	Caches that normalize QUERY content incorrectly or in ways that are		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 the incorrect response if normalization results in a false		can return the 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]).
	skipping to change at page 9, line 49 ¶		skipping to change at page 9, line 49 ¶
	[STRUCTURED-FIELDS]		[STRUCTURED-FIELDS]
	Nottingham, M. and P-H. Kamp, "Structured Field Values for		Nottingham, M. and P-H. 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>.
	6.2. Informative References		6.2. Informative References
	[FETCH] WHATWG, "FETCH", <https://fetch.spec.whatwg.org>.		[FETCH] WHATWG, "FETCH", <https://fetch.spec.whatwg.org>.
			[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
			Specifications and Registration Procedures", BCP 13,
			RFC 6838, DOI 10.17487/RFC6838, January 2013,
			<https://www.rfc-editor.org/info/rfc6838>.
			[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
			Interchange Format", STD 90, RFC 8259,
			DOI 10.17487/RFC8259, December 2017,
			<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>.
	[XSLT] Kay, M., "XSL Transformations (XSLT) Version 3.0", W3C		[XSLT] Kay, M., "XSL Transformations (XSLT) Version 3.0", W3C
	Recommendation REC-xslt-30-20170608, June 8, 2017,		Recommendation REC-xslt-30-20170608, 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 probably better		to send queries that are actually this short, it is probably better
	to use GET.		to 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,
	The Content-Length fields have been omitted for brevity.		defined in "application/x-www-form-urlencoded
			(https://url.spec.whatwg.org/#application/x-www-form-urlencoded)" in
			[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:		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
	skipping to change at page 11, line 19 ¶		skipping to change at page 11, line 39 ¶
	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 could respond with a
	4xx status such as 405 ("Method Not Allowed", Section 15.5.6 of		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		Discovery of supported media types for QUERY is possible via the
	Accept-Query (Section 3) response field:		Accept-Query (Section 3) response field:
	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 415 (Unsupported
	Media Type", Section 12.5.1 of [HTTP]) response - to inspect the		Media Type, Section 12.5.1 of [HTTP]) response -- to inspect the
	Allow (Section 15.5.16 of [HTTP]) response field:		Allow (Section 15.5.16 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
	The Content-Location and Location response fields provide a way to		The Content-Location and Location response fields provide a way to
	identify alternate resources that will respond to GET requests,		identify alternate resources that will respond to GET requests,
	skipping to change at page 14, line 4 ¶		skipping to change at page 14, line 37 ¶
	"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 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		Note that there's 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.3. Indirect Responses		A.4.3. Indirect Responses
	Servers can send "indirect" responses using the status code 303 ("See		Servers can send "indirect" responses using the status code 303 (See
	Other", Section 15.4.4 of [HTTP]).		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 an alternative resource. This resource could then be
	used as shown in Appendix A.4.2.		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 database of RFC		The following examples show requests on a JSON-shaped ([RFC8259])
	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
	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"
	skipping to change at page 16, line 40 ¶		skipping to change at page 17, 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 would report the identifiers of all rejected errata submitted		below would report the identifiers of all rejected errata submitted
	since 2024:		since 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"
	skipping to change at page 20, line 13 ¶		skipping to change at page 21, line 13 ¶
	extensions/issues/2957>)		extensions/issues/2957>)
	B.8. Since draft-ietf-httpbis-safe-method-w-body-07		B.8. Since draft-ietf-httpbis-safe-method-w-body-07
	o Examples Section revised (<https://github.com/httpwg/http-		o Examples Section revised (<https://github.com/httpwg/http-
	extensions/issues/1906>)		extensions/issues/1906>)
	o Discuss Range Requests (<https://github.com/httpwg/http-		o Discuss Range Requests (<https://github.com/httpwg/http-
	extensions/issues/2979>)		extensions/issues/2979>)
			B.9. Since draft-ietf-httpbis-safe-method-w-body-08
			o Avoid term 'query parameters' (<https://github.com/httpwg/http-
			extensions/issues/3019>)
			o Add missing references, fixed terminology
			(<https://github.com/httpwg/http-extensions/issues/3021>)
			o Add Acknowledgements/Contributors sections; moved Ashok to
			Contributors (<https://github.com/httpwg/http-extensions/
			issues/3029>)
			Acknowledgements
			We thank all members of the HTTP Working Group for ideas, reviews,
			and feedback.
			The following individuals deserve special recognition: Carsten
			Bormann, Mark Nottingham, Martin Thomson, Michael Thornburgh, Roberto
			Polli, Roy Fielding, and Will Hawkins.
			Contributors
			Ashok Malhotra participated in early discussions leading to this
			specification:
			Ashok Malhotra
			Email: malhotrasahib@gmail.com
	Authors' Addresses		Authors' Addresses
	Julian Reschke		Julian Reschke
	greenbytes GmbH		greenbytes GmbH
	Hafenweg 16		Hafenweg 16
	48155 Münster		48155 Münster
	Germany		Germany
	Email: julian.reschke@greenbytes.de		Email: julian.reschke@greenbytes.de
	URI: https://greenbytes.de/tech/webdav/		URI: https://greenbytes.de/tech/webdav/
	Ashok Malhotra
	Email: malhotrasahib@gmail.com
	James M Snell		James M Snell
	Email: jasnell@gmail.com		Email: jasnell@gmail.com
	Mike Bishop		Mike Bishop
	Akamai		Akamai
	Email: mbishop@evequefou.be		Email: mbishop@evequefou.be
End of changes. 29 change blocks.
	58 lines changed or deleted		101 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/