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 14, 2026 Cloudflare
M. Bishop M. Bishop
Akamai Akamai
May 19, 2025 July 13, 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 January 14, 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 . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 15
A.5. More Query Formats . . . . . . . . . . . . . . . . . . . 15 A.5. More Query Formats . . . . . . . . . . . . . . . . . . . 16
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])
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. 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
skipping to change at page 6, line 5 skipping to change at page 6, line 25
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.
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 12, line 46 skipping to change at page 13, line 33
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 20 skipping to change at page 15, line 4
{ "surname": "Smith", { "surname": "Smith",
"givenname": "John", "givenname": "John",
"email": "smith@example.org" }, "email": "smith@example.org" },
{ "surname": "Jones", { "surname": "Jones",
"givenname": "Sally", "givenname": "Sally",
"email": "sally.jones@example.com" }, "email": "sally.jones@example.com" },
{ "surname": "Dubois", { "surname": "Dubois",
"givenname": "Camille", "givenname": "Camille",
"email": "camille.dubois@example.net" } "email": "camille.dubois@example.net" }
] ]
Note that there's no guarantee that the server will implement this
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 38
[ [
{ "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 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 abstract
(<https://github.com/httpwg/http-extensions/issues/3121>)
o Address HTTPDIR/RF feedback on introduction
(<https://github.com/httpwg/http-extensions/issues/3122>)
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. 32 change blocks. 
70 lines changed or deleted 107 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/