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: January 1, 2026 Cloudflare
	M. Bishop		M. Bishop
	Akamai		Akamai
	May 19, 2025		June 30, 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 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.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 January 1, 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
	skipping to change at page 2, line 25 ¶		skipping to change at page 2, line 25 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . 4
	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 . . . . . . . . . . . . . . . . . . . . . . . 6
	2.4. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 7		2.4. Conditional Requests . . . . . . . . . . . . . . . . . . 7
	2.5. Range Requests . . . . . . . . . . . . . . . . . . . . . 7		2.5. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 7
			2.6. Range Requests . . . . . . . . . . . . . . . . . . . . . 7
	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 . . . . . . . . . . . . . . . . . . . . . 9		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	5.1. Registration of QUERY method . . . . . . . . . . . . . . 9		5.1. Registration of QUERY method . . . . . . . . . . . . . . 9
	5.2. Registration of Accept-Query field . . . . . . . . . . . 9		5.2. Registration of Accept-Query field . . . . . . . . . . . 9
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	6.1. Normative References . . . . . . . . . . . . . . . . . . 9		6.1. Normative References . . . . . . . . . . . . . . . . . . 9
	6.2. Informative References . . . . . . . . . . . . . . . . . 10		6.2. Informative References . . . . . . . . . . . . . . . . . 10
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 11
	A.1. Simple Query . . . . . . . . . . . . . . . . . . . . . . 11		A.1. Simple Query . . . . . . . . . . . . . . . . . . . . . . 11
	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 . . . . . . . . . . . . . . . 12
	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 . . . . . . . . . . . . . . . 13
	A.4.2. Using Location . . . . . . . . . . . . . . . . . . . 14		A.4.2. Using Location . . . . . . . . . . . . . . . . . . . 14
	A.4.3. Indirect Responses . . . . . . . . . . . . . . . . . 15		A.4.3. Indirect Responses . . . . . . . . . . . . . . . . . 15
	A.5. More Query Formats . . . . . . . . . . . . . . . . . . . 15		A.5. More Query Formats . . . . . . . . . . . . . . . . . . . 15
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 18		Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 19
	B.1. Since draft-ietf-httpbis-safe-method-w-body-00 . . . . . 18		B.1. Since draft-ietf-httpbis-safe-method-w-body-00 . . . . . 19
	B.2. Since draft-ietf-httpbis-safe-method-w-body-01 . . . . . 19		B.2. Since draft-ietf-httpbis-safe-method-w-body-01 . . . . . 20
	B.3. Since draft-ietf-httpbis-safe-method-w-body-02 . . . . . 19		B.3. Since draft-ietf-httpbis-safe-method-w-body-02 . . . . . 20
	B.4. Since draft-ietf-httpbis-safe-method-w-body-03 . . . . . 19		B.4. Since draft-ietf-httpbis-safe-method-w-body-03 . . . . . 20
	B.5. Since draft-ietf-httpbis-safe-method-w-body-04 . . . . . 19		B.5. Since draft-ietf-httpbis-safe-method-w-body-04 . . . . . 20
	B.6. Since draft-ietf-httpbis-safe-method-w-body-05 . . . . . 19		B.6. Since draft-ietf-httpbis-safe-method-w-body-05 . . . . . 20
	B.7. Since draft-ietf-httpbis-safe-method-w-body-06 . . . . . 20		B.7. Since draft-ietf-httpbis-safe-method-w-body-06 . . . . . 21
	B.8. Since draft-ietf-httpbis-safe-method-w-body-07 . . . . . 21		B.8. Since draft-ietf-httpbis-safe-method-w-body-07 . . . . . 22
	B.9. Since draft-ietf-httpbis-safe-method-w-body-08 . . . . . 21		B.9. Since draft-ietf-httpbis-safe-method-w-body-08 . . . . . 22
	B.10. Since draft-ietf-httpbis-safe-method-w-body-09 . . . . . 21		B.10. Since draft-ietf-httpbis-safe-method-w-body-09 . . . . . 22
	B.11. Since draft-ietf-httpbis-safe-method-w-body-10 . . . . . 21		B.11. Since draft-ietf-httpbis-safe-method-w-body-10 . . . . . 22
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22		B.12. Since draft-ietf-httpbis-safe-method-w-body-11 . . . . . 23
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 22		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22		Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 23
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
	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]) that
	contains content.		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:
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 5 ¶
	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]). The semantics of the redirect response do
	not differ from other methods.		not differ from other methods.
	For instance, a 303 (See Other, Section 15.4.4 of [HTTP]) response		For instance, a 303 (See Other, Section 15.4.4 of [HTTP]) response
	would indicate that the Location field identifies an alternate URI		would indicate that the Location field identifies an alternate URI
	from which the results can be retrieved using a GET request (this use		from which the results can be retrieved using a GET request (this use
	case is also covered by the use of the Location response field in a		case is also covered by the use of the Location response field in a
	2xx response).		2xx response).
	On the other hand, response codes 307 (Temporary Redirect,		On the other hand, response codes 307 (Temporary Redirect,
	Section 15.4.8 of [HTTP]) and 308 (Permanent Redirect, Section 15.4.9		Section 15.4.8 of [HTTP]) and 308 (Permanent Redirect, Section 15.4.9
	of [HTTP]) can be used to request the user agent to redo the QUERY		of [HTTP]) can be used to request the user agent to redo the QUERY
	request on the URI specified by the Location field.		request on the URI specified by the Location field.
	Various non-normative examples of successful QUERY responses are		Various non-normative examples of successful QUERY responses are
	illustrated in Appendix A.		illustrated in Appendix A.
	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. When doing so, caches SHOULD
	first normalize request content to remove semantically insignificant		first normalize request content to remove semantically insignificant
	differences, thereby improving cache efficiency, by:		differences, thereby improving cache efficiency, by:
	skipping to change at page 7, line 28 ¶		skipping to change at page 7, line 35 ¶
	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 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.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 12, line 46 ¶		skipping to change at page 13, line 7 ¶
	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 14, 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 15, 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 23, 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 Address HTTPDIR/RF feedback on example appendix
			(<https://github.com/httpwg/http-extensions/issues/3114>)
	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. 24 change blocks.
	48 lines changed or deleted		64 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/