draft-ietf-httpbis-semantics-15.txt   draft-ietf-httpbis-semantics-latest.txt 
HTTP Working Group R. Fielding, Ed. HTTP Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 2818, 7230, 7231, 7232, 7233, 7235, M. Nottingham, Ed. Obsoletes: 2818, 7230, 7231, 7232, 7233, 7235, M. Nottingham, Ed.
7538, 7615, 7694 (if approved) Fastly 7538, 7615, 7694 (if approved) Fastly
Updates: 3864 (if approved) J. Reschke, Ed. Updates: 3864 (if approved) J. Reschke, Ed.
Intended status: Standards Track greenbytes Intended status: Standards Track greenbytes
Expires: October 1, 2021 March 30, 2021 Expires: October 24, 2021 April 22, 2021
HTTP Semantics HTTP Semantics
draft-ietf-httpbis-semantics-15 draft-ietf-httpbis-semantics-latest
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypertext information level protocol for distributed, collaborative, hypertext information
systems. This document describes the overall architecture of HTTP, systems. This document describes the overall architecture of HTTP,
establishes common terminology, and defines aspects of the protocol establishes common terminology, and defines aspects of the protocol
that are shared by all versions. In this definition are core that are shared by all versions. In this definition are core
protocol elements, extensibility mechanisms, and the "http" and protocol elements, extensibility mechanisms, and the "http" and
"https" Uniform Resource Identifier (URI) schemes. "https" Uniform Resource Identifier (URI) schemes.
This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC
7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230. 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions
of RFC 7230.
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-core>. <https://github.com/httpwg/http-core>.
The changes in this draft are summarized in Appendix C.16. The changes in this draft are summarized in Appendix C.17.
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 1, 2021. This Internet-Draft will expire on October 24, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 8, line 51 skipping to change at page 9, line 7
19.1. Normative References . . . . . . . . . . . . . . . . . . 196 19.1. Normative References . . . . . . . . . . . . . . . . . . 196
19.2. Informative References . . . . . . . . . . . . . . . . . 198 19.2. Informative References . . . . . . . . . . . . . . . . . 198
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 204 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 204
Appendix B. Changes from previous RFCs . . . . . . . . . . . . . 209 Appendix B. Changes from previous RFCs . . . . . . . . . . . . . 209
B.1. Changes from RFC 2818 . . . . . . . . . . . . . . . . . . 209 B.1. Changes from RFC 2818 . . . . . . . . . . . . . . . . . . 209
B.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 209 B.2. Changes from RFC 7230 . . . . . . . . . . . . . . . . . . 209
B.3. Changes from RFC 7231 . . . . . . . . . . . . . . . . . . 210 B.3. Changes from RFC 7231 . . . . . . . . . . . . . . . . . . 210
B.4. Changes from RFC 7232 . . . . . . . . . . . . . . . . . . 212 B.4. Changes from RFC 7232 . . . . . . . . . . . . . . . . . . 212
B.5. Changes from RFC 7233 . . . . . . . . . . . . . . . . . . 212 B.5. Changes from RFC 7233 . . . . . . . . . . . . . . . . . . 212
B.6. Changes from RFC 7235 . . . . . . . . . . . . . . . . . . 212 B.6. Changes from RFC 7235 . . . . . . . . . . . . . . . . . . 212
B.7. Changes from RFC 7538 . . . . . . . . . . . . . . . . . . 212 B.7. Changes from RFC 7538 . . . . . . . . . . . . . . . . . . 213
B.8. Changes from RFC 7615 . . . . . . . . . . . . . . . . . . 213 B.8. Changes from RFC 7615 . . . . . . . . . . . . . . . . . . 213
B.9. Changes from RFC 7694 . . . . . . . . . . . . . . . . . . 213 B.9. Changes from RFC 7694 . . . . . . . . . . . . . . . . . . 213
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 213 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 213
C.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 213 C.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 213
C.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 213 C.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 213
C.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 214 C.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 214
C.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 215 C.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 215
C.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 216 C.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 216
C.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 217 C.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 217
C.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 217 C.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 217
C.8. Since draft-ietf-httpbis-semantics-06 . . . . . . . . . . 219 C.8. Since draft-ietf-httpbis-semantics-06 . . . . . . . . . . 219
C.9. Since draft-ietf-httpbis-semantics-07 . . . . . . . . . . 220 C.9. Since draft-ietf-httpbis-semantics-07 . . . . . . . . . . 220
C.10. Since draft-ietf-httpbis-semantics-08 . . . . . . . . . . 221 C.10. Since draft-ietf-httpbis-semantics-08 . . . . . . . . . . 221
C.11. Since draft-ietf-httpbis-semantics-09 . . . . . . . . . . 223 C.11. Since draft-ietf-httpbis-semantics-09 . . . . . . . . . . 223
C.12. Since draft-ietf-httpbis-semantics-10 . . . . . . . . . . 223 C.12. Since draft-ietf-httpbis-semantics-10 . . . . . . . . . . 223
C.13. Since draft-ietf-httpbis-semantics-11 . . . . . . . . . . 224 C.13. Since draft-ietf-httpbis-semantics-11 . . . . . . . . . . 225
C.14. Since draft-ietf-httpbis-semantics-12 . . . . . . . . . . 225 C.14. Since draft-ietf-httpbis-semantics-12 . . . . . . . . . . 225
C.15. Since draft-ietf-httpbis-semantics-13 . . . . . . . . . . 227 C.15. Since draft-ietf-httpbis-semantics-13 . . . . . . . . . . 227
C.16. Since draft-ietf-httpbis-semantics-14 . . . . . . . . . . 227 C.16. Since draft-ietf-httpbis-semantics-14 . . . . . . . . . . 227
C.17. Since draft-ietf-httpbis-semantics-15 . . . . . . . . . . 230
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 230 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 230
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 242 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 242
1. Introduction 1. Introduction
1.1. Purpose 1.1. Purpose
The Hypertext Transfer Protocol (HTTP) is a family of stateless, The Hypertext Transfer Protocol (HTTP) is a family of stateless,
application-level, request/response protocols that share a generic application-level, request/response protocols that share a generic
interface, extensible semantics, and self-descriptive messages to interface, extensible semantics, and self-descriptive messages to
enable flexible interaction with network-based hypertext information enable flexible interaction with network-based hypertext information
skipping to change at page 86, line 5 skipping to change at page 86, line 5
determined only while generating the content. For example, some determined only while generating the content. For example, some
servers buffer a dynamic response to GET until a minimum amount of servers buffer a dynamic response to GET until a minimum amount of
data is generated so that they can more efficiently delimit small data is generated so that they can more efficiently delimit small
responses or make late decisions with regard to content selection. responses or make late decisions with regard to content selection.
Such a response to GET might contain Content-Length and Vary fields, Such a response to GET might contain Content-Length and Vary fields,
for example, that are not generated within a HEAD response. These for example, that are not generated within a HEAD response. These
minor inconsistencies are considered preferable to generating and minor inconsistencies are considered preferable to generating and
discarding the content for a HEAD request, since HEAD is usually discarding the content for a HEAD request, since HEAD is usually
requested for the sake of efficiency. requested for the sake of efficiency.
A content within a HEAD request message has no defined semantics; A client SHOULD NOT generate content in a HEAD request. Content
sending content in a HEAD request might cause some existing received in a HEAD request has no defined semantics, cannot alter the
implementations to reject the request. meaning or target of the request, and might lead some implementations
to reject the request and close the connection because of its
potential as a request smuggling attack (Section 11.2 of
[Messaging]).
The response to a HEAD request is cacheable; a cache MAY use it to The response to a HEAD request is cacheable; a cache MAY use it to
satisfy subsequent HEAD requests unless otherwise indicated by the satisfy subsequent HEAD requests unless otherwise indicated by the
Cache-Control header field (Section 5.2 of [Caching]). A HEAD Cache-Control header field (Section 5.2 of [Caching]). A HEAD
response might also affect previously cached responses to GET; see response might also affect previously cached responses to GET; see
Section 4.3.5 of [Caching]. Section 4.3.5 of [Caching].
9.3.3. POST 9.3.3. POST
The POST method requests that the target resource process the The POST method requests that the target resource process the
skipping to change at page 196, line 29 skipping to change at page 196, line 29
+------+-------------------+-------------------------+------+ +------+-------------------+-------------------------+------+
Table 12 Table 12
19. References 19. References
19.1. Normative References 19.1. Normative References
[Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", Work in Progress, Internet-Draft, Ed., "HTTP Caching", Work in Progress, Internet-Draft,
draft-ietf-httpbis-cache-latest, March 2021, draft-ietf-httpbis-cache-latest, April 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-cache- <https://tools.ietf.org/html/draft-ietf-httpbis-cache-
latest>. latest>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC1950] Deutsch, L.P. and J-L. Gailly, "ZLIB Compressed Data [RFC1950] Deutsch, L.P. and J-L. Gailly, "ZLIB Compressed Data
Format Specification version 3.3", RFC 1950, Format Specification version 3.3", RFC 1950,
DOI 10.17487/RFC1950, May 1996, DOI 10.17487/RFC1950, May 1996,
skipping to change at page 199, line 44 skipping to change at page 199, line 44
character sets -- Part 1: Latin alphabet No. 1", ISO/ character sets -- Part 1: Latin alphabet No. 1", ISO/
IEC 8859-1:1998, 1998. IEC 8859-1:1998, 1998.
[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
Politics", ACM Transactions on Internet Technology 1(2), Politics", ACM Transactions on Internet Technology 1(2),
November 2001, <http://arxiv.org/abs/cs.SE/0105018>. November 2001, <http://arxiv.org/abs/cs.SE/0105018>.
[Messaging] [Messaging]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", Work in Progress, Internet-Draft, draft- Ed., "HTTP/1.1", Work in Progress, Internet-Draft, draft-
ietf-httpbis-messaging-latest, March 2021, ietf-httpbis-messaging-latest, April 2021,
<https://tools.ietf.org/html/draft-ietf-httpbis-messaging- <https://tools.ietf.org/html/draft-ietf-httpbis-messaging-
latest>. latest>.
[OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web [OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web
Applications and Web Services", The Open Web Application Applications and Web Services", The Open Web Application
Security Project (OWASP) 2.0.1, July 27, 2005, Security Project (OWASP) 2.0.1, July 27, 2005,
<https://www.owasp.org/>. <https://www.owasp.org/>.
[REST] Fielding, R.T., "Architectural Styles and the Design of [REST] Fielding, R.T., "Architectural Styles and the Design of
Network-based Software Architectures", Network-based Software Architectures",
skipping to change at page 202, line 46 skipping to change at page 202, line 46
[RFC7232] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext [RFC7232] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Conditional Requests", Transfer Protocol (HTTP/1.1): Conditional Requests",
RFC 7232, DOI 10.17487/RFC7232, June 2014, RFC 7232, DOI 10.17487/RFC7232, June 2014,
<https://www.rfc-editor.org/info/rfc7232>. <https://www.rfc-editor.org/info/rfc7232>.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. F. Reschke, Ed., [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. F. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range Requests", "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
RFC 7233, DOI 10.17487/RFC7233, June 2014, RFC 7233, DOI 10.17487/RFC7233, June 2014,
<https://www.rfc-editor.org/info/rfc7233>. <https://www.rfc-editor.org/info/rfc7233>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. F. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014,
<https://www.rfc-editor.org/info/rfc7234>.
[RFC7235] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext [RFC7235] Fielding, R., Ed. and J. F. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, Transfer Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014, DOI 10.17487/RFC7235, June 2014,
<https://www.rfc-editor.org/info/rfc7235>. <https://www.rfc-editor.org/info/rfc7235>.
[RFC7538] Reschke, J. F., "The Hypertext Transfer Protocol Status [RFC7538] Reschke, J. F., "The Hypertext Transfer Protocol Status
Code 308 (Permanent Redirect)", RFC 7538, Code 308 (Permanent Redirect)", RFC 7538,
DOI 10.17487/RFC7538, April 2015, DOI 10.17487/RFC7538, April 2015,
<https://www.rfc-editor.org/info/rfc7538>. <https://www.rfc-editor.org/info/rfc7538>.
skipping to change at page 210, line 46 skipping to change at page 211, line 4
An abstract data type for HTTP messages has been introduced to define An abstract data type for HTTP messages has been introduced to define
the components of a message and their semantics as an abstraction the components of a message and their semantics as an abstraction
across multiple HTTP versions, rather than in terms of the specific across multiple HTTP versions, rather than in terms of the specific
syntax form of HTTP/1.1 in [Messaging], and reflect the contents syntax form of HTTP/1.1 in [Messaging], and reflect the contents
after the message is parsed. This makes it easier to distinguish after the message is parsed. This makes it easier to distinguish
between requirements on the content (what is conveyed) versus between requirements on the content (what is conveyed) versus
requirements on the messaging syntax (how it is conveyed) and avoids requirements on the messaging syntax (how it is conveyed) and avoids
baking limitations of early protocol versions into the future of baking limitations of early protocol versions into the future of
HTTP. (Section 6) HTTP. (Section 6)
The terms "payload" and "payload body" have been replaced with The terms "payload" and "payload body" have been replaced with
"content", to better align with its usage elsewhere (e.g., in field "content", to better align with its usage elsewhere (e.g., in field
names) and to avoid confusion with frame payloads in HTTP/2 and names) and to avoid confusion with frame payloads in HTTP/2 and
HTTP/3. (Section 6.4) HTTP/3. (Section 6.4)
The term "effective request URI" has been replaced with "target URI". The term "effective request URI" has been replaced with "target URI".
(Section 7.1) (Section 7.1)
Restrictions on client retries have been loosened, to reflect Restrictions on client retries have been loosened, to reflect
implementation behavior. (Section 9.2.2) implementation behavior. (Section 9.2.2)
Clarified that request bodies on GET and DELETE are not Clarified that request bodies on GET, HEAD, and DELETE are not
interoperable. (Section 9.3.1, Section 9.3.5) interoperable. (Section 9.3.1, Section 9.3.2, Section 9.3.5)
Allowed use of the Content-Range header field (Section 14.4) as a Allowed use of the Content-Range header field (Section 14.4) as a
request modifier on PUT. (Section 9.3.4) request modifier on PUT. (Section 9.3.4)
Removed a superfluous requirement about setting Content-Length from Removed a superfluous requirement about setting Content-Length from
the description of the OPTIONS method. (Section 9.3.7) the description of the OPTIONS method. (Section 9.3.7)
Removed normative requirement to use the "message/http" media type in Removed normative requirement to use the "message/http" media type in
TRACE responses. (Section 9.3.8) TRACE responses. (Section 9.3.8)
skipping to change at page 230, line 5 skipping to change at page 230, line 15
o In Section 10.1.5, note that the Trailer field can be used to o In Section 10.1.5, note that the Trailer field can be used to
discover deleted trailers (<https://github.com/httpwg/http-core/ discover deleted trailers (<https://github.com/httpwg/http-core/
issues/793>) issues/793>)
o Throughout, remove unneeded normative references to [Messaging] o Throughout, remove unneeded normative references to [Messaging]
(<https://github.com/httpwg/http-core/issues/795>) (<https://github.com/httpwg/http-core/issues/795>)
o In Section 10.1.4, explicitly require listing in Connection o In Section 10.1.4, explicitly require listing in Connection
(<https://github.com/httpwg/http-core/issues/809>) (<https://github.com/httpwg/http-core/issues/809>)
C.17. Since draft-ietf-httpbis-semantics-15
o In Section 9.3.2, align prose about content in HEAD requests with
description of GET (<https://github.com/httpwg/http-core/
issues/826>)
Acknowledgments Acknowledgments
This edition of the HTTP specification builds on the many Aside from the current editors, the following individuals deserve
contributions that went into RFC 1945, RFC 2068, RFC 2145, RFC 2616, special recognition for their contributions to early aspects of HTTP
and RFC 2818, including substantial contributions made by the current and its core specifications: Marc Andreessen, Tim Berners-Lee, Robert
and previous editors of HTTP: Tim Berners-Lee, Jean-François Groff, Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jim Gettys,
Ari Luotonen, Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Jean-François Groff, Phillip M. Hallam-Baker, Koen Holtman, Jeffery
Larry Masinter, Paul J. Leach, Eric Rescorla, and Yves Lafon. L. Hostetler, Shel Kaphan, Dave Kristol, Yves Lafon, Scott
D. Lawrence, Paul J. Leach, Håkon W. Lie, Ari Luotonen, Larry
Masinter, Rob McCool, Jeffrey C. Mogul, Lou Montulli, David Morris,
Henrik Frystyk Nielsen, Dave Raggett, Eric Rescorla, Tony Sanders,
Lawrence C. Stewart, Marc VanHeyningen, and Steve Zilles.
In addition, this document has reincorporated the HTTP Authentication This edition builds on the many contributions that went into past
Framework, previously defined in RFC 7235 and RFC 2617. We thank specifications of HTTP, including RFC 1945, RFC 2068, RFC 2145, RFC
John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott 2616, RFC 2617, RFC 2818, RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC
D. Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart 7234, and RFC 7235. The acknowledgements within those documents
for their work on that specification. See Section 6 of [RFC2617] for still apply.
further acknowledgements.
Since 2014, the following contributors have helped improve the HTTP Since 2014, the following contributors have helped improve this
specification by reporting bugs, asking smart questions, drafting or specification by reporting bugs, asking smart questions, drafting or
reviewing text, and evaluating open issues: reviewing text, and evaluating open issues:
Alan Egerton, Alex Rousskov, Amichai Rothman, Amos Jeffries, Anders Alan Egerton, Alex Rousskov, Amichai Rothman, Amos Jeffries, Anders
Kaseorg, Andreas Gebhardt, Anne van Kesteren, Armin Abfalterer, Aron Kaseorg, Andreas Gebhardt, Anne van Kesteren, Armin Abfalterer, Aron
Duby, Asanka Herath, Asbjørn Ulsberg, Attila Gulyas, Austin Wright, Duby, Asanka Herath, Asbjørn Ulsberg, Attila Gulyas, Austin Wright,
Barry Pollard, Ben Burkert, Björn Höhrmann, Brad Fitzpatrick, Chris Barry Pollard, Ben Burkert, Björn Höhrmann, Brad Fitzpatrick, Chris
Pacejo, Colin Bendell, Cory Benfield, Cory Nelson, Daisuke Miyakawa, Pacejo, Colin Bendell, Cory Benfield, Cory Nelson, Daisuke Miyakawa,
Daniel Stenberg, Danil Suits, David Benjamin, David Matson, David Daniel Stenberg, Danil Suits, David Benjamin, David Matson, David
Schinazi, Дилян Палаузов (Dilyan Palauzov), Eric Anderson, Eric Schinazi, Дилян Палаузов (Dilyan Palauzov), Eric Anderson, Eric
skipping to change at page 230, line 44 skipping to change at page 231, line 14
Yasskin, Kalin Gyokov, Kannan Goundan, 奥 一穂 (Kazuho Oku), Ken Yasskin, Kalin Gyokov, Kannan Goundan, 奥 一穂 (Kazuho Oku), Ken
Murchison, Krzysztof Maczyński, Lucas Pardue, Martin Dürst, Martin Murchison, Krzysztof Maczyński, Lucas Pardue, Martin Dürst, Martin
Thomson, Martynas Jusevičius, Matt Menke, Matthias Pigulla, Michael Thomson, Martynas Jusevičius, Matt Menke, Matthias Pigulla, Michael
Osipov, Mike Bishop, Mike Pennisi, Mike Taylor, Mike West, Nathaniel Osipov, Mike Bishop, Mike Pennisi, Mike Taylor, Mike West, Nathaniel
J. Smith, Nicholas Hurley, Nikita Piskunov, Patrick McManus, Piotr J. Smith, Nicholas Hurley, Nikita Piskunov, Patrick McManus, Piotr
Sikora, Poul-Henning Kamp, Rick van Rein, Roberto Polli, Semyon Sikora, Poul-Henning Kamp, Rick van Rein, Roberto Polli, Semyon
Kholodnov, Simon Pieters, Simon Schüppel, Todd Greer, Tommy Pauly, Kholodnov, Simon Pieters, Simon Schüppel, Todd Greer, Tommy Pauly,
Vasiliy Faronov, Vladimir Lashchev, Wenbo Zhu, William A. Rowe Jr., Vasiliy Faronov, Vladimir Lashchev, Wenbo Zhu, William A. Rowe Jr.,
Willy Tarreau, Xingwei Liu, and Yishuai Li. Willy Tarreau, Xingwei Liu, and Yishuai Li.
See Section 10 of [RFC7230] for further acknowledgements from prior
revisions.
Index Index
1 2 3 4 5 A B C D E F G H I L M N O P R S T U V W X 1 2 3 4 5 A B C D E F G H I L M N O P R S T U V W X
1 1
100 Continue (status code) 15.2.1 100 Continue (status code) 15.2.1
100-continue (expect value) 10.1.1 100-continue (expect value) 10.1.1
101 Switching Protocols (status code) 15.2.2 101 Switching Protocols (status code) 15.2.2
1xx Informational (status code class) 15.2 1xx Informational (status code class) 15.2
2 2
200 OK (status code) 15.3.1 200 OK (status code) 15.3.1
 End of changes. 22 change blocks. 
33 lines changed or deleted 50 lines changed or added

This html diff was produced by rfcdiff 1.44jr. The latest version is available from http://tools.ietf.org/tools/rfcdiff/