draft-ietf-httpbis-safe-method-w-body-10.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: October 31, 2025		Expires: November 12, 2025
	M. Bishop		M. Bishop
	Akamai		Akamai
	April 29, 2025		May 11, 2025
	The HTTP QUERY Method		The HTTP QUERY Method
	draft-ietf-httpbis-safe-method-w-body-10		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.10.		The changes in this draft are summarized in Appendix B.11.
	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 October 31, 2025.		This Internet-Draft will expire on November 12, 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 28 ¶		skipping to change at page 2, line 28 ¶
	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 and Location Fields . . . . . . . . . . 6
	2.2. Redirection . . . . . . . . . . . . . . . . . . . . . . . 6		2.2. Redirection . . . . . . . . . . . . . . . . . . . . . . . 6
	2.3. Conditional Requests . . . . . . . . . . . . . . . . . . 6		2.3. Conditional Requests . . . . . . . . . . . . . . . . . . 6
	2.4. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 6		2.4. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 7
	2.5. Range Requests . . . . . . . . . . . . . . . . . . . . . 7		2.5. 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 . . . . . . . . . . . . . . . . . . . . . 8		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 . . . . . . . . . . . . . . . . . . . . . . 10		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 . . . . . . . . . . . . . . . 11
	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 . . . 12
	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 . . . . . . . . . . . . . . . . . . . . . 18
	B.1. Since draft-ietf-httpbis-safe-method-w-body-00 . . . . . 18		B.1. Since draft-ietf-httpbis-safe-method-w-body-00 . . . . . 18
	B.2. Since draft-ietf-httpbis-safe-method-w-body-01 . . . . . 19		B.2. Since draft-ietf-httpbis-safe-method-w-body-01 . . . . . 19
	B.3. Since draft-ietf-httpbis-safe-method-w-body-02 . . . . . 19		B.3. Since draft-ietf-httpbis-safe-method-w-body-02 . . . . . 19
	B.4. Since draft-ietf-httpbis-safe-method-w-body-03 . . . . . 19		B.4. Since draft-ietf-httpbis-safe-method-w-body-03 . . . . . 19
	B.5. Since draft-ietf-httpbis-safe-method-w-body-04 . . . . . 19		B.5. Since draft-ietf-httpbis-safe-method-w-body-04 . . . . . 19
	B.6. Since draft-ietf-httpbis-safe-method-w-body-05 . . . . . 19		B.6. Since draft-ietf-httpbis-safe-method-w-body-05 . . . . . 19
	B.7. Since draft-ietf-httpbis-safe-method-w-body-06 . . . . . 20		B.7. Since draft-ietf-httpbis-safe-method-w-body-06 . . . . . 20
	B.8. Since draft-ietf-httpbis-safe-method-w-body-07 . . . . . 21		B.8. Since draft-ietf-httpbis-safe-method-w-body-07 . . . . . 21
	B.9. Since draft-ietf-httpbis-safe-method-w-body-08 . . . . . 21		B.9. Since draft-ietf-httpbis-safe-method-w-body-08 . . . . . 21
	B.10. Since draft-ietf-httpbis-safe-method-w-body-09 . . . . . 21		B.10. Since draft-ietf-httpbis-safe-method-w-body-09 . . . . . 21
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21		B.11. Since draft-ietf-httpbis-safe-method-w-body-10 . . . . . 21
			Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 22		Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	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,
	skipping to change at page 4, line 45 ¶		skipping to change at page 4, line 45 ¶
	| 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 |		| Cacheable | yes | yes | yes, but only |
	| | | | for future GET |		| | | | for future GET |
	| | | | or HEAD requests |		| | | | or HEAD requests |
	| Content | "no | expected | expected |		| Content | "no | expected | expected |
	| (body) | defined | (semantics per | (semantics per |		| (body) | defined | (semantics per | (semantics per |
	| | semantics" | target resource) | target resource) |		| | semantics" | target resource) | target resource) |
	+------------+------------+------------------+------------------+		+------------+------------+------------------+------------------+
	Table 1		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 4.2.2 of [HTTP]) of a QUERY		content_ for the request content (Section 4.2.2 of [HTTP]) of a QUERY
	request.		request.
	skipping to change at page 5, line 25 ¶		skipping to change at page 5, line 25 ¶
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. QUERY		2. QUERY
	The QUERY method is used to initiate a server-side query. Unlike the		The QUERY method is used to initiate a server-side query. Unlike the
	HTTP GET method, which requests that a server return a representation		HTTP GET method, which requests that a server return a representation
	of the resource identified by the target URI (as defined by		of the resource identified by the target URI (as defined by
	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 at the resource. The content returned in response
	response to a QUERY cannot be assumed to be a representation of the		to a QUERY cannot be assumed to be a representation of the resource
	resource identified by the target URI.		identified by the target URI.
	The content of the request and it's media type define the query.		The content of the request and it's media type define the query.
	Implementations MAY use a request content of any media type with the		Implementations MAY use a request content of any media type with the
	QUERY method, provided that it has appropriate query semantics.		QUERY method, provided that it has appropriate query semantics.
	As for all HTTP methods in general, the target URI's query part takes		As for all HTTP methods in general, the target URI's query part takes
	part in identifying the resource being queried and therefore is not		part in identifying the resource being queried and therefore is not
	part of the actual query. Whether and how the URI's query part		part of the actual query. Whether and how the URI's query part
	directly affects the result of the query is implementation specific		directly affects the result of the query is implementation specific
	and out of scope for this specification.		and out of scope for this specification.
	QUERY requests are both safe and idempotent with regard 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 identified 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 (2xx, Section 15.3 of [HTTP]) can		A successful response (2xx, Section 15.3 of [HTTP]) can include a
	include a Content-Location header field containing an identifier for		Content-Location header field containing an identifier for a resource
	a resource corresponding to the results of the operation; see		corresponding to the results of the operation; see Section 8.7 of
	Section 8.7 of [HTTP] for details. This represents a claim from the		[HTTP] for details. This represents a claim from the server that a
	server that a client can send a GET request for the indicated URI to		client can send a GET request for the indicated URI to retrieve the
	retrieve the results of the query operation just performed. The		results of the query operation just performed. The indicated
	indicated resource might be temporary.		resource might be temporary.
	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		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.
	response would indicate that the Location field identifies an
	alternate URI from which the results can be retrieved using a GET		For instance, a 303 (See Other) response would indicate that the
	request (this use case is also covered by the use of the Location		Location field identifies an alternate URI from which the results can
	response field in a 2xx response). On the other hand, response codes		be retrieved using a GET request (this use case is also covered by
	307 (Temporary Redirect) and 308 (Permanent Redirect) can be used to		the use of the Location response field in a 2xx response).
	request the user agent to redo the QUERY request on the URI specified
	by the Location field. Various non-normative examples of successful		On the other hand, response codes 307 (Temporary Redirect) and 308
	QUERY responses are illustrated in Appendix A.		(Permanent Redirect) 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
			illustrated in Appendix A.
	2.3. Conditional Requests		2.3. 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.4. 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 (see Section 2 of [HTTP-CACHING]) MUST		The cache key for a QUERY request (see Section 2 of [HTTP-CACHING])
	incorporate the request content. When doing so, caches SHOULD first		MUST incorporate the request content. When doing so, caches SHOULD
	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:
	o Removing content encoding(s) (Section 8.4 of [HTTP]).		o Removing content encoding(s) (Section 8.4 of [HTTP]).
	o Normalizing based upon knowledge of format conventions, as		o Normalizing based upon knowledge of format conventions, as
	indicated by any media subtype suffix in the request's Content-		indicated by any media subtype suffix in the request's Content-
	Type field (e.g., "+json", see Section 4.2.8 of [RFC6838]).		Type field (e.g., "+json", see Section 4.2.8 of [RFC6838]).
	o Normalizing based upon knowledge of the semantics of the content		o Normalizing based upon knowledge of the semantics of the content
	itself, as indicated by the request's Content-Type field.		itself, as indicated by the request's Content-Type field.
	skipping to change at page 8, line 30 ¶		skipping to change at page 8, line 35 ¶
	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 component). This is preferred in some		the URI (e.g., in the query component). This is preferred in some
	cases, as the URI is more likely to be logged or otherwise processed		cases, as the URI is more likely to be logged or otherwise processed
	by intermediaries than the request content.		by intermediaries than the request content. In other cases, where
			the query contains sensitive information, the potential for logging
			of the URI might motivate the use of QUERY over GET.
	If a server creates a temporary resource to represent the results of		If a server creates a temporary resource to represent the results of
	a QUERY request (e.g., for use in the Location or Content-Location		a QUERY request (e.g., for use in the Location or Content-Location
	field) and the request contains sensitive information that cannot be		field) and the request contains sensitive information that cannot be
	logged, then the URI of this resource SHOULD be chosen such that it		logged, then the URI of this resource SHOULD be chosen such that it
	does not include any sensitive portions of the original request		does not include any sensitive portions of the original request
	content.		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 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 |
	skipping to change at page 10, line 49 ¶		skipping to change at page 11, line 8 ¶
	[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 likely better to
	to use GET.		use GET.
	The media type used in most examples is "application/x-www-form-		The media type used in most examples is "application/x-www-form-
	urlencoded" (as used in POST requests from browser user clients,		urlencoded" (as used in POST requests from browser user clients,
	defined in "application/x-www-form-urlencoded		defined in "application/x-www-form-urlencoded
	(https://url.spec.whatwg.org/#application/x-www-form-urlencoded)" in		(https://url.spec.whatwg.org/#application/x-www-form-urlencoded)" in
	[URL]). The Content-Length fields have been omitted for brevity.		[URL]). The Content-Length fields have been omitted for brevity.
	A.1. Simple Query		A.1. Simple Query
	A simple query with a direct response:		A simple query with a direct response:
	skipping to change at page 21, line 47 ¶		skipping to change at page 21, line 47 ¶
	URI semantics (<https://github.com/httpwg/http-extensions/		URI semantics (<https://github.com/httpwg/http-extensions/
	issues/3069>)		issues/3069>)
	o Restrict description of Content-Location and Location semantics to		o Restrict description of Content-Location and Location semantics to
	2xx responses (<https://github.com/httpwg/http-extensions/		2xx responses (<https://github.com/httpwg/http-extensions/
	issues/3070>)		issues/3070>)
	o Slightly rephrase semantics for Content-Location		o Slightly rephrase semantics for Content-Location
	(<https://github.com/httpwg/http-extensions/issues/3071>)		(<https://github.com/httpwg/http-extensions/issues/3071>)
			B.11. Since draft-ietf-httpbis-safe-method-w-body-10
			o Editorial nits (<https://github.com/httpwg/http-extensions/
			pull/3080>, ack martinthomson)
	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. 20 change blocks.
	37 lines changed or deleted		50 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/