source: draft-ietf-httpbis/latest/auth48/rfc7230.abdiff.txt @ 2632

Last change on this file since 2632 was 2632, checked in by julian.reschke@…, 9 years ago

prune change logs, add AUTH48 statement to "Editorial Note" (#553)

File size: 105.5 KB
Line 
1
2INTRODUCTION, paragraph 1:
3OLD:
4
5 HTTPbis Working Group                                   R. Fielding, Ed.
6 Internet-Draft                                                     Adobe
7 Obsoletes: 2145,2616 (if approved)                       J. Reschke, Ed.
8 Updates: 2817,2818 (if approved)                              greenbytes
9 Intended status: Standards Track                             May 6, 2014
10 Expires: November 7, 2014
11
12NEW:
13
14 Internet Engineering Task Force (IETF)                  R. Fielding, Ed.
15 Request for Comments: 7230                                         Adobe
16 Obsoletes: 2145, 2616                                    J. Reschke, Ed.
17 Updates: 2817, 2818                                           greenbytes
18 Category: Standards Track                                       May 2014
19 ISSN: 2070-1721
20
21
22INTRODUCTION, paragraph 2:
23OLD:
24
25    Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
26                  draft-ietf-httpbis-p1-messaging-latest
27
28NEW:
29
30    Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
31
32
33INTRODUCTION, paragraph 5:
34OLD:
35
36 Editorial Note (To be removed by RFC Editor)
37 
38    Discussion of this draft takes place on the HTTPBIS working group
39    mailing list (ietf-http-wg@w3.org), which is archived at
40    <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
41 
42    The current issues list is at
43    <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
44    documents (including fancy diffs) can be found at
45    <http://tools.ietf.org/wg/httpbis/>.
46 
47    _This is a temporary document for the purpose of tracking the
48    editorial changes made during the AUTH48 (RFC publication) phase._
49 
50 Status of This Memo
51
52NEW:
53
54 Status of This Memo
55
56
57INTRODUCTION, paragraph 6:
58OLD:
59
60    This Internet-Draft is submitted in full conformance with the
61    provisions of BCP 78 and BCP 79.
62 
63    Internet-Drafts are working documents of the Internet Engineering
64    Task Force (IETF).  Note that other groups may also distribute
65    working documents as Internet-Drafts.  The list of current Internet-
66    Drafts is at http://datatracker.ietf.org/drafts/current/.
67
68NEW:
69
70    This is an Internet Standards Track document.
71
72
73INTRODUCTION, paragraph 7:
74OLD:
75
76    Internet-Drafts are draft documents valid for a maximum of six months
77    and may be updated, replaced, or obsoleted by other documents at any
78    time.  It is inappropriate to use Internet-Drafts as reference
79    material or to cite them other than as "work in progress."
80
81NEW:
82
83    This document is a product of the Internet Engineering Task Force
84    (IETF).  It represents the consensus of the IETF community.  It has
85    received public review and has been approved for publication by the
86    Internet Engineering Steering Group (IESG).  Further information on
87    Internet Standards is available in Section 2 of RFC 5741.
88
89
90INTRODUCTION, paragraph 8:
91OLD:
92
93    This Internet-Draft will expire on November 7, 2014.
94
95NEW:
96
97    Information about the current status of this document, any errata,
98    and how to provide feedback on it may be obtained at
99    http://www.rfc-editor.org/info/rfc7230.
100
101
102Section 11., paragraph 0:
103OLD:
104
105    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
106      1.1.  Requirement Notation . . . . . . . . . . . . . . . . . . .  6
107      1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  6
108    2.  Architecture . . . . . . . . . . . . . . . . . . . . . . . . .  6
109      2.1.  Client/Server Messaging  . . . . . . . . . . . . . . . . .  7
110      2.2.  Implementation Diversity . . . . . . . . . . . . . . . . .  8
111      2.3.  Intermediaries . . . . . . . . . . . . . . . . . . . . . .  9
112      2.4.  Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11
113      2.5.  Conformance and Error Handling . . . . . . . . . . . . . . 12
114      2.6.  Protocol Versioning  . . . . . . . . . . . . . . . . . . . 13
115      2.7.  Uniform Resource Identifiers . . . . . . . . . . . . . . . 16
116        2.7.1.  http URI scheme  . . . . . . . . . . . . . . . . . . . 16
117        2.7.2.  https URI scheme . . . . . . . . . . . . . . . . . . . 18
118        2.7.3.  http and https URI Normalization and Comparison  . . . 19
119    3.  Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19
120      3.1.  Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20
121        3.1.1.  Request Line . . . . . . . . . . . . . . . . . . . . . 21
122        3.1.2.  Status Line  . . . . . . . . . . . . . . . . . . . . . 22
123      3.2.  Header Fields  . . . . . . . . . . . . . . . . . . . . . . 22
124        3.2.1.  Field Extensibility  . . . . . . . . . . . . . . . . . 23
125        3.2.2.  Field Order  . . . . . . . . . . . . . . . . . . . . . 23
126        3.2.3.  Whitespace . . . . . . . . . . . . . . . . . . . . . . 24
127        3.2.4.  Field Parsing  . . . . . . . . . . . . . . . . . . . . 25
128        3.2.5.  Field Limits . . . . . . . . . . . . . . . . . . . . . 26
129        3.2.6.  Field value components . . . . . . . . . . . . . . . . 26
130      3.3.  Message Body . . . . . . . . . . . . . . . . . . . . . . . 27
131        3.3.1.  Transfer-Encoding  . . . . . . . . . . . . . . . . . . 28
132        3.3.2.  Content-Length . . . . . . . . . . . . . . . . . . . . 30
133        3.3.3.  Message Body Length  . . . . . . . . . . . . . . . . . 31
134      3.4.  Handling Incomplete Messages . . . . . . . . . . . . . . . 33
135      3.5.  Message Parsing Robustness . . . . . . . . . . . . . . . . 34
136    4.  Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 35
137      4.1.  Chunked Transfer Coding  . . . . . . . . . . . . . . . . . 35
138        4.1.1.  Chunk Extensions . . . . . . . . . . . . . . . . . . . 36
139        4.1.2.  Chunked Trailer Part . . . . . . . . . . . . . . . . . 36
140        4.1.3.  Decoding Chunked . . . . . . . . . . . . . . . . . . . 37
141      4.2.  Compression Codings  . . . . . . . . . . . . . . . . . . . 38
142        4.2.1.  Compress Coding  . . . . . . . . . . . . . . . . . . . 38
143        4.2.2.  Deflate Coding . . . . . . . . . . . . . . . . . . . . 38
144        4.2.3.  Gzip Coding  . . . . . . . . . . . . . . . . . . . . . 38
145      4.3.  TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
146      4.4.  Trailer  . . . . . . . . . . . . . . . . . . . . . . . . . 39
147    5.  Message Routing  . . . . . . . . . . . . . . . . . . . . . . . 40
148      5.1.  Identifying a Target Resource  . . . . . . . . . . . . . . 40
149      5.2.  Connecting Inbound . . . . . . . . . . . . . . . . . . . . 40
150      5.3.  Request Target . . . . . . . . . . . . . . . . . . . . . . 41
151        5.3.1.  origin-form  . . . . . . . . . . . . . . . . . . . . . 41
152        5.3.2.  absolute-form  . . . . . . . . . . . . . . . . . . . . 42
153        5.3.3.  authority-form . . . . . . . . . . . . . . . . . . . . 42
154        5.3.4.  asterisk-form  . . . . . . . . . . . . . . . . . . . . 42
155      5.4.  Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
156      5.5.  Effective Request URI  . . . . . . . . . . . . . . . . . . 44
157      5.6.  Associating a Response to a Request  . . . . . . . . . . . 46
158      5.7.  Message Forwarding . . . . . . . . . . . . . . . . . . . . 46
159        5.7.1.  Via  . . . . . . . . . . . . . . . . . . . . . . . . . 47
160        5.7.2.  Transformations  . . . . . . . . . . . . . . . . . . . 48
161    6.  Connection Management  . . . . . . . . . . . . . . . . . . . . 49
162      6.1.  Connection . . . . . . . . . . . . . . . . . . . . . . . . 50
163      6.2.  Establishment  . . . . . . . . . . . . . . . . . . . . . . 51
164      6.3.  Persistence  . . . . . . . . . . . . . . . . . . . . . . . 52
165        6.3.1.  Retrying Requests  . . . . . . . . . . . . . . . . . . 53
166        6.3.2.  Pipelining . . . . . . . . . . . . . . . . . . . . . . 53
167      6.4.  Concurrency  . . . . . . . . . . . . . . . . . . . . . . . 54
168      6.5.  Failures and Time-outs . . . . . . . . . . . . . . . . . . 54
169      6.6.  Tear-down  . . . . . . . . . . . . . . . . . . . . . . . . 55
170      6.7.  Upgrade  . . . . . . . . . . . . . . . . . . . . . . . . . 56
171    7.  ABNF list extension: #rule . . . . . . . . . . . . . . . . . . 58
172    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 60
173      8.1.  Header Field Registration  . . . . . . . . . . . . . . . . 60
174      8.2.  URI Scheme Registration  . . . . . . . . . . . . . . . . . 60
175      8.3.  Internet Media Type Registration . . . . . . . . . . . . . 61
176        8.3.1.  Internet Media Type message/http . . . . . . . . . . . 61
177        8.3.2.  Internet Media Type application/http . . . . . . . . . 62
178      8.4.  Transfer Coding Registry . . . . . . . . . . . . . . . . . 63
179        8.4.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 63
180        8.4.2.  Registration . . . . . . . . . . . . . . . . . . . . . 64
181      8.5.  Content Coding Registration  . . . . . . . . . . . . . . . 64
182      8.6.  Upgrade Token Registry . . . . . . . . . . . . . . . . . . 65
183        8.6.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 65
184        8.6.2.  Upgrade Token Registration . . . . . . . . . . . . . . 66
185    9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 66
186      9.1.  Establishing Authority . . . . . . . . . . . . . . . . . . 66
187      9.2.  Risks of Intermediaries  . . . . . . . . . . . . . . . . . 67
188      9.3.  Attacks via Protocol Element Length  . . . . . . . . . . . 68
189      9.4.  Response Splitting . . . . . . . . . . . . . . . . . . . . 68
190      9.5.  Request Smuggling  . . . . . . . . . . . . . . . . . . . . 69
191      9.6.  Message Integrity  . . . . . . . . . . . . . . . . . . . . 69
192      9.7.  Message Confidentiality  . . . . . . . . . . . . . . . . . 70
193      9.8.  Privacy of Server Log Information  . . . . . . . . . . . . 70
194    10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 71
195    11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
196      11.1. Normative References . . . . . . . . . . . . . . . . . . . 72
197      11.2. Informative References . . . . . . . . . . . . . . . . . . 74
198    Appendix A.  HTTP Version History  . . . . . . . . . . . . . . . . 76
199      A.1.  Changes from HTTP/1.0  . . . . . . . . . . . . . . . . . . 77
200        A.1.1.  Multi-homed Web Servers  . . . . . . . . . . . . . . . 77
201        A.1.2.  Keep-Alive Connections . . . . . . . . . . . . . . . . 77
202        A.1.3.  Introduction of Transfer-Encoding  . . . . . . . . . . 78
203      A.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 78
204    Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 80
205    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
206
207NEW:
208
209    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
210      1.1.  Requirements Notation  . . . . . . . . . . . . . . . . . .  6
211      1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  6
212    2.  Architecture . . . . . . . . . . . . . . . . . . . . . . . . .  6
213      2.1.  Client/Server Messaging  . . . . . . . . . . . . . . . . .  7
214      2.2.  Implementation Diversity . . . . . . . . . . . . . . . . .  8
215      2.3.  Intermediaries . . . . . . . . . . . . . . . . . . . . . .  9
216      2.4.  Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11
217      2.5.  Conformance and Error Handling . . . . . . . . . . . . . . 12
218      2.6.  Protocol Versioning  . . . . . . . . . . . . . . . . . . . 13
219      2.7.  Uniform Resource Identifiers . . . . . . . . . . . . . . . 16
220        2.7.1.  http URI Scheme  . . . . . . . . . . . . . . . . . . . 16
221        2.7.2.  https URI Scheme . . . . . . . . . . . . . . . . . . . 18
222        2.7.3.  http and https URI Normalization and Comparison  . . . 19
223    3.  Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19
224      3.1.  Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20
225        3.1.1.  Request Line . . . . . . . . . . . . . . . . . . . . . 21
226        3.1.2.  Status Line  . . . . . . . . . . . . . . . . . . . . . 22
227      3.2.  Header Fields  . . . . . . . . . . . . . . . . . . . . . . 22
228        3.2.1.  Field Extensibility  . . . . . . . . . . . . . . . . . 23
229        3.2.2.  Field Order  . . . . . . . . . . . . . . . . . . . . . 23
230        3.2.3.  Whitespace . . . . . . . . . . . . . . . . . . . . . . 24
231        3.2.4.  Field Parsing  . . . . . . . . . . . . . . . . . . . . 25
232        3.2.5.  Field Limits . . . . . . . . . . . . . . . . . . . . . 26
233        3.2.6.  Field Value Components . . . . . . . . . . . . . . . . 26
234      3.3.  Message Body . . . . . . . . . . . . . . . . . . . . . . . 27
235        3.3.1.  Transfer-Encoding  . . . . . . . . . . . . . . . . . . 28
236        3.3.2.  Content-Length . . . . . . . . . . . . . . . . . . . . 30
237        3.3.3.  Message Body Length  . . . . . . . . . . . . . . . . . 31
238      3.4.  Handling Incomplete Messages . . . . . . . . . . . . . . . 33
239      3.5.  Message Parsing Robustness . . . . . . . . . . . . . . . . 34
240    4.  Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 35
241      4.1.  Chunked Transfer Coding  . . . . . . . . . . . . . . . . . 35
242        4.1.1.  Chunk Extensions . . . . . . . . . . . . . . . . . . . 36
243        4.1.2.  Chunked Trailer Part . . . . . . . . . . . . . . . . . 36
244        4.1.3.  Decoding Chunked . . . . . . . . . . . . . . . . . . . 37
245      4.2.  Compression Codings  . . . . . . . . . . . . . . . . . . . 38
246        4.2.1.  Compress Coding  . . . . . . . . . . . . . . . . . . . 38
247        4.2.2.  Deflate Coding . . . . . . . . . . . . . . . . . . . . 38
248        4.2.3.  Gzip Coding  . . . . . . . . . . . . . . . . . . . . . 38
249      4.3.  TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
250      4.4.  Trailer  . . . . . . . . . . . . . . . . . . . . . . . . . 39
251    5.  Message Routing  . . . . . . . . . . . . . . . . . . . . . . . 40
252      5.1.  Identifying a Target Resource  . . . . . . . . . . . . . . 40
253      5.2.  Connecting Inbound . . . . . . . . . . . . . . . . . . . . 40
254      5.3.  Request Target . . . . . . . . . . . . . . . . . . . . . . 41
255        5.3.1.  origin-form  . . . . . . . . . . . . . . . . . . . . . 41
256        5.3.2.  absolute-form  . . . . . . . . . . . . . . . . . . . . 42
257        5.3.3.  authority-form . . . . . . . . . . . . . . . . . . . . 42
258        5.3.4.  asterisk-form  . . . . . . . . . . . . . . . . . . . . 42
259      5.4.  Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
260      5.5.  Effective Request URI  . . . . . . . . . . . . . . . . . . 44
261      5.6.  Associating a Response to a Request  . . . . . . . . . . . 46
262      5.7.  Message Forwarding . . . . . . . . . . . . . . . . . . . . 46
263        5.7.1.  Via  . . . . . . . . . . . . . . . . . . . . . . . . . 47
264        5.7.2.  Transformations  . . . . . . . . . . . . . . . . . . . 48
265    6.  Connection Management  . . . . . . . . . . . . . . . . . . . . 49
266      6.1.  Connection . . . . . . . . . . . . . . . . . . . . . . . . 50
267      6.2.  Establishment  . . . . . . . . . . . . . . . . . . . . . . 51
268      6.3.  Persistence  . . . . . . . . . . . . . . . . . . . . . . . 52
269        6.3.1.  Retrying Requests  . . . . . . . . . . . . . . . . . . 53
270        6.3.2.  Pipelining . . . . . . . . . . . . . . . . . . . . . . 53
271      6.4.  Concurrency  . . . . . . . . . . . . . . . . . . . . . . . 54
272      6.5.  Failures and Timeouts  . . . . . . . . . . . . . . . . . . 54
273      6.6.  Teardown . . . . . . . . . . . . . . . . . . . . . . . . . 55
274      6.7.  Upgrade  . . . . . . . . . . . . . . . . . . . . . . . . . 56
275    7.  ABNF List Extension: #rule . . . . . . . . . . . . . . . . . . 58
276    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 60
277      8.1.  Header Field Registration  . . . . . . . . . . . . . . . . 60
278      8.2.  URI Scheme Registration  . . . . . . . . . . . . . . . . . 60
279      8.3.  Internet Media Type Registration . . . . . . . . . . . . . 61
280        8.3.1.  Internet Media Type message/http . . . . . . . . . . . 61
281        8.3.2.  Internet Media Type application/http . . . . . . . . . 62
282      8.4.  Transfer Coding Registry . . . . . . . . . . . . . . . . . 63
283        8.4.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 63
284        8.4.2.  Registration . . . . . . . . . . . . . . . . . . . . . 64
285      8.5.  Content Coding Registration  . . . . . . . . . . . . . . . 64
286      8.6.  Upgrade Token Registry . . . . . . . . . . . . . . . . . . 65
287        8.6.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 65
288        8.6.2.  Upgrade Token Registration . . . . . . . . . . . . . . 66
289    9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 66
290      9.1.  Establishing Authority . . . . . . . . . . . . . . . . . . 66
291      9.2.  Risks of Intermediaries  . . . . . . . . . . . . . . . . . 67
292      9.3.  Attacks via Protocol Element Length  . . . . . . . . . . . 68
293      9.4.  Response Splitting . . . . . . . . . . . . . . . . . . . . 68
294      9.5.  Request Smuggling  . . . . . . . . . . . . . . . . . . . . 69
295      9.6.  Message Integrity  . . . . . . . . . . . . . . . . . . . . 69
296      9.7.  Message Confidentiality  . . . . . . . . . . . . . . . . . 70
297      9.8.  Privacy of Server Log Information  . . . . . . . . . . . . 70
298    10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 71
299    11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
300      11.1. Normative References . . . . . . . . . . . . . . . . . . . 72
301      11.2. Informative References . . . . . . . . . . . . . . . . . . 74
302    Appendix A.  HTTP Version History  . . . . . . . . . . . . . . . . 76
303      A.1.  Changes from HTTP/1.0  . . . . . . . . . . . . . . . . . . 76
304        A.1.1.  Multihomed Web Servers . . . . . . . . . . . . . . . . 77
305        A.1.2.  Keep-Alive Connections . . . . . . . . . . . . . . . . 77
306        A.1.3.  Introduction of Transfer-Encoding  . . . . . . . . . . 78
307      A.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 78
308    Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 80
309    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
310
311
312Section 1., paragraph 8:
313OLD:
314
315    This HTTP/1.1 specification obsoletes RFC 2616 and RFC 2145 (on HTTP
316    versioning).  This specification also updates the use of CONNECT to
317    establish a tunnel, previously defined in RFC 2817, and defines the
318    "https" URI scheme that was described informally in RFC 2818.
319
320NEW:
321
322    This HTTP/1.1 specification obsoletes [RFC2616] and [RFC2145] (on
323    HTTP versioning).  This specification also updates the use of
324    CONNECT, previously defined in RFC 2817, to establish a tunnel, and
325    defines the "https" URI scheme that was described informally in RFC
326    2818.
327
328
329Section 1., paragraph 13:
330OLD:
331
332 1.1.  Requirement Notation
333
334NEW:
335
336 1.1.  Requirements Notation
337
338
339Section 2.1., paragraph 1:
340OLD:
341
342    HTTP is a stateless request/response protocol that operates by
343    exchanging messages (Section 3) across a reliable transport or
344    session-layer "connection" (Section 6).  An HTTP "client" is a
345    program that establishes a connection to a server for the purpose of
346    sending one or more HTTP requests.  An HTTP "server" is a program
347    that accepts connections in order to service HTTP requests by sending
348    HTTP responses.
349
350NEW:
351
352    HTTP is a stateless request/response protocol that operates by
353    exchanging messages (Section 3) across a reliable transport- or
354    session-layer "connection" (Section 6).  An HTTP "client" is a
355    program that establishes a connection to a server for the purpose of
356    sending one or more HTTP requests.  An HTTP "server" is a program
357    that accepts connections in order to service HTTP requests by sending
358    HTTP responses.
359
360
361Section 2.1., paragraph 2:
362OLD:
363
364    The terms client and server refer only to the roles that these
365    programs perform for a particular connection.  The same program might
366    act as a client on some connections and a server on others.  The term
367    "user agent" refers to any of the various client programs that
368    initiate a request, including (but not limited to) browsers, spiders
369    (web-based robots), command-line tools, custom applications, and
370    mobile apps.  The term "origin server" refers to the program that can
371    originate authoritative responses for a given target resource.  The
372    terms "sender" and "recipient" refer to any implementation that sends
373    or receives a given message, respectively.
374
375NEW:
376
377    The terms "client" and "server" refer only to the roles that these
378    programs perform for a particular connection.  The same program might
379    act as a client on some connections and a server on others.  The term
380    "user agent" refers to any of the various client programs that
381    initiate a request, including (but not limited to) browsers, spiders
382    (web-based robots), command-line tools, custom applications, and
383    mobile apps.  The term "origin server" refers to the program that can
384    originate authoritative responses for a given target resource.  The
385    terms "sender" and "recipient" refer to any implementation that sends
386    or receives a given message, respectively.
387
388
389Section 2.2., paragraph 1:
390OLD:
391
392    When considering the design of HTTP, it is easy to fall into a trap
393    of thinking that all user agents are general-purpose browsers and all
394    origin servers are large public websites.  That is not the case in
395    practice.  Common HTTP user agents include household appliances,
396    stereos, scales, firmware update scripts, command-line programs,
397    mobile apps, and communication devices in a multitude of shapes and
398    sizes.  Likewise, common HTTP origin servers include home automation
399    units, configurable networking components, office machines,
400    autonomous robots, news feeds, traffic cameras, ad selectors, and
401    video delivery platforms.
402
403NEW:
404
405    When considering the design of HTTP, it is easy to fall into a trap
406    of thinking that all user agents are general-purpose browsers and all
407    origin servers are large public websites.  That is not the case in
408    practice.  Common HTTP user agents include household appliances,
409    stereos, scales, firmware update scripts, command-line programs,
410    mobile apps, and communication devices in a multitude of shapes and
411    sizes.  Likewise, common HTTP origin servers include home automation
412    units, configurable networking components, office machines,
413    autonomous robots, news feeds, traffic cameras, ad selectors, and
414    video-delivery platforms.
415
416
417Section 2.3., paragraph 3:
418OLD:
419
420    The figure above shows three intermediaries (A, B, and C) between the
421    user agent and origin server.  A request or response message that
422    travels the whole chain will pass through four separate connections.
423    Some HTTP communication options might apply only to the connection
424    with the nearest, non-tunnel neighbor, only to the end-points of the
425    chain, or to all connections along the chain.  Although the diagram
426    is linear, each participant might be engaged in multiple,
427    simultaneous communications.  For example, B might be receiving
428    requests from many clients other than A, and/or forwarding requests
429    to servers other than C, at the same time that it is handling A's
430    request.  Likewise, later requests might be sent through a different
431    path of connections, often based on dynamic configuration for load
432    balancing.
433
434NEW:
435
436    The figure above shows three intermediaries (A, B, and C) between the
437    user agent and origin server.  A request or response message that
438    travels the whole chain will pass through four separate connections.
439    Some HTTP communication options might apply only to the connection
440    with the nearest, non-tunnel neighbor, only to the endpoints of the
441    chain, or to all connections along the chain.  Although the diagram
442    is linear, each participant might be engaged in multiple,
443    simultaneous communications.  For example, B might be receiving
444    requests from many clients other than A, and/or forwarding requests
445    to servers other than C, at the same time that it is handling A's
446    request.  Likewise, later requests might be sent through a different
447    path of connections, often based on dynamic configuration for load
448    balancing.
449
450
451Section 2.3., paragraph 4:
452OLD:
453
454    The terms "upstream" and "downstream" are used to describe
455    directional requirements in relation to the message flow: all
456    messages flow from upstream to downstream.  The terms inbound and
457    outbound are used to describe directional requirements in relation to
458    the request route: "inbound" means toward the origin server and
459    "outbound" means toward the user agent.
460
461NEW:
462
463    The terms "upstream" and "downstream" are used to describe
464    directional requirements in relation to the message flow: all
465    messages flow from upstream to downstream.  The terms "inbound" and
466    "outbound" are used to describe directional requirements in relation
467    to the request route: "inbound" means toward the origin server and
468    "outbound" means toward the user agent.
469
470
471Section 2.3., paragraph 5:
472OLD:
473
474    A "proxy" is a message forwarding agent that is selected by the
475    client, usually via local configuration rules, to receive requests
476    for some type(s) of absolute URI and attempt to satisfy those
477    requests via translation through the HTTP interface.  Some
478    translations are minimal, such as for proxy requests for "http" URIs,
479    whereas other requests might require translation to and from entirely
480    different application-level protocols.  Proxies are often used to
481    group an organization's HTTP requests through a common intermediary
482    for the sake of security, annotation services, or shared caching.
483    Some proxies are designed to apply transformations to selected
484    messages or payloads while they are being forwarded, as described in
485    Section 5.7.2.
486
487NEW:
488
489    A "proxy" is a message-forwarding agent that is selected by the
490    client, usually via local configuration rules, to receive requests
491    for some type(s) of absolute URI and attempt to satisfy those
492    requests via translation through the HTTP interface.  Some
493    translations are minimal, such as for proxy requests for "http" URIs,
494    whereas other requests might require translation to and from entirely
495    different application-level protocols.  Proxies are often used to
496    group an organization's HTTP requests through a common intermediary
497    for the sake of security, annotation services, or shared caching.
498    Some proxies are designed to apply transformations to selected
499    messages or payloads while they are being forwarded, as described in
500    Section 5.7.2.
501
502
503Section 2.3., paragraph 6:
504OLD:
505
506    A "gateway" (a.k.a., "reverse proxy") is an intermediary that acts as
507    an origin server for the outbound connection, but translates received
508    requests and forwards them inbound to another server or servers.
509    Gateways are often used to encapsulate legacy or untrusted
510    information services, to improve server performance through
511    "accelerator" caching, and to enable partitioning or load balancing
512    of HTTP services across multiple machines.
513
514NEW:
515
516    A "gateway" (a.k.a. "reverse proxy") is an intermediary that acts as
517    an origin server for the outbound connection but translates received
518    requests and forwards them inbound to another server or servers.
519    Gateways are often used to encapsulate legacy or untrusted
520    information services, to improve server performance through
521    "accelerator" caching, and to enable partitioning or load balancing
522    of HTTP services across multiple machines.
523
524
525Section 2.3., paragraph 7:
526OLD:
527
528    All HTTP requirements applicable to an origin server also apply to
529    the outbound communication of a gateway.  A gateway communicates with
530    inbound servers using any protocol that it desires, including private
531    extensions to HTTP that are outside the scope of this specification.
532    However, an HTTP-to-HTTP gateway that wishes to interoperate with
533    third-party HTTP servers ought to conform to user agent requirements
534    on the gateway's inbound connection.
535
536NEW:
537
538    All HTTP requirements applicable to an origin server also apply to
539    the outbound communication of a gateway.  A gateway communicates with
540    inbound servers using any protocol that it desires, including private
541    extensions to HTTP that are outside the scope of this specification.
542    However, an HTTP-to-HTTP gateway that wishes to interoperate with
543    third-party HTTP servers ought to conform to user-agent requirements
544    on the gateway's inbound connection.
545
546
547Section 2.3., paragraph 11:
548OLD:
549
550    HTTP is defined as a stateless protocol, meaning that each request
551    message can be understood in isolation.  Many implementations depend
552    on HTTP's stateless design in order to reuse proxied connections or
553    dynamically load-balance requests across multiple servers.  Hence, a
554    server MUST NOT assume that two requests on the same connection are
555    from the same user agent unless the connection is secured and
556    specific to that agent.  Some non-standard HTTP extensions (e.g.,
557    [RFC4559]) have been known to violate this requirement, resulting in
558    security and interoperability problems.
559
560NEW:
561
562    HTTP is defined as a stateless protocol, meaning that each request
563    message can be understood in isolation.  Many implementations depend
564    on HTTP's stateless design in order to reuse proxied connections or
565    dynamically load balance requests across multiple servers.  Hence, a
566    server MUST NOT assume that two requests on the same connection are
567    from the same user agent unless the connection is secured and
568    specific to that agent.  Some non-standard HTTP extensions (e.g.,
569    [RFC4559]) have been known to violate this requirement, resulting in
570    security and interoperability problems.
571
572
573Section 2.4., paragraph 5:
574OLD:
575
576    There are a wide variety of architectures and configurations of
577    caches deployed across the World Wide Web and inside large
578    organizations.  These include national hierarchies of proxy caches to
579    save transoceanic bandwidth, collaborative systems that broadcast or
580    multicast cache entries, archives of pre-fetched cache entries for
581    use in off-line or high-latency environments, and so on.
582
583NEW:
584
585    There is a wide variety of architectures and configurations of caches
586    deployed across the World Wide Web and inside large organizations.
587    These include national hierarchies of proxy caches to save
588    transoceanic bandwidth, collaborative systems that broadcast or
589    multicast cache entries, archives of pre-fetched cache entries for
590    use in off-line or high-latency environments, and so on.
591
592
593Section 2.5., paragraph 5:
594OLD:
595
596    When a received protocol element is parsed, the recipient MUST be
597    able to parse any value of reasonable length that is applicable to
598    the recipient's role and matches the grammar defined by the
599    corresponding ABNF rules.  Note, however, that some received protocol
600    elements might not be parsed.  For example, an intermediary
601    forwarding a message might parse a header-field into generic field-
602    name and field-value components, but then forward the header field
603    without further parsing inside the field-value.
604
605NEW:
606
607    When a received protocol element is parsed, the recipient MUST be
608    able to parse any value of reasonable length that is applicable to
609    the recipient's role and that matches the grammar defined by the
610    corresponding ABNF rules.  Note, however, that some received protocol
611    elements might not be parsed.  For example, an intermediary
612    forwarding a message might parse a header-field into generic field-
613    name and field-value components, but then forward the header field
614    without further parsing inside the field-value.
615
616
617Section 2.5., paragraph 6:
618OLD:
619
620    HTTP does not have specific length limitations for many of its
621    protocol elements because the lengths that might be appropriate will
622    vary widely, depending on the deployment context and purpose of the
623    implementation.  Hence, interoperability between senders and
624    recipients depends on shared expectations regarding what is a
625    reasonable length for each protocol element.  Furthermore, what is
626    commonly understood to be a reasonable length for some protocol
627    elements has changed over the course of the past two decades of HTTP
628    use, and is expected to continue changing in the future.
629
630NEW:
631
632    HTTP does not have specific length limitations for many of its
633    protocol elements because the lengths that might be appropriate will
634    vary widely, depending on the deployment context and purpose of the
635    implementation.  Hence, interoperability between senders and
636    recipients depends on shared expectations regarding what is a
637    reasonable length for each protocol element.  Furthermore, what is
638    commonly understood to be a reasonable length for some protocol
639    elements has changed over the course of the past two decades of HTTP
640    use and is expected to continue changing in the future.
641
642
643Section 2.6., paragraph 2:
644OLD:
645
646    The version of an HTTP message is indicated by an HTTP-version field
647    in the first line of the message.  HTTP-version is case-sensitive.
648
649NEW:
650
651    The version of an HTTP message is indicated by an HTTP-version field
652    in the first line of the message.  HTTP-version is case sensitive.
653
654
655Section 2.6., paragraph 3:
656OLD:
657
658      HTTP-version  = HTTP-name "/" DIGIT "." DIGIT
659      HTTP-name     = %x48.54.54.50 ; "HTTP", case-sensitive
660
661NEW:
662
663      HTTP-version  = HTTP-name "/" DIGIT "." DIGIT
664      HTTP-name     = %x48.54.54.50 ; "HTTP", case sensitive
665
666
667Section 2.6., paragraph 7:
668OLD:
669
670    New header fields can be introduced without changing the protocol
671    version if their defined semantics allow them to be safely ignored by
672    recipients that do not recognize them.  Header field extensibility is
673    discussed in Section 3.2.1.
674
675NEW:
676
677    New header fields can be introduced without changing the protocol
678    version if their defined semantics allow them to be safely ignored by
679    recipients that do not recognize them.  Header-field extensibility is
680    discussed in Section 3.2.1.
681
682
683Section 2.6., paragraph 14:
684OLD:
685
686    When an HTTP message is received with a major version number that the
687    recipient implements, but a higher minor version number than what the
688    recipient implements, the recipient SHOULD process the message as if
689    it were in the highest minor version within that major version to
690    which the recipient is conformant.  A recipient can assume that a
691    message with a higher minor version, when sent to a recipient that
692    has not yet indicated support for that higher version, is
693    sufficiently backwards-compatible to be safely processed by any
694    implementation of the same major version.
695
696NEW:
697
698    When an HTTP message is received with a major version number that the
699    recipient implements, but a higher minor version number than what the
700    recipient implements, the recipient SHOULD process the message as if
701    it were in the highest minor version within that major version to
702    which the recipient is conformant.  A recipient can assume that a
703    message with a higher minor version, when sent to a recipient that
704    has not yet indicated support for that higher version, is
705    sufficiently backwards compatible to be safely processed by any
706    implementation of the same major version.
707
708
709Section 2.7., paragraph 2:
710OLD:
711
712    The definitions of "URI-reference", "absolute-URI", "relative-part",
713    "scheme", "authority", "port", "host", "path-abempty", "segment",
714    "query", and "fragment" are adopted from the URI generic syntax.  An
715    "absolute-path" rule is defined for protocol elements that can
716    contain a non-empty path component.  (This rule differs slightly from
717    RFC 3986's path-abempty rule, which allows for an empty path to be
718    used in references, and path-absolute rule, which does not allow
719    paths that begin with "//".)  A "partial-URI" rule is defined for
720    protocol elements that can contain a relative URI but not a fragment
721    component.
722
723NEW:
724
725    The definitions of "URI-reference", "absolute-URI", "relative-part",
726    "scheme", "authority", "port", "host", "path-abempty", "segment",
727    "query", and "fragment" are adopted from the URI generic syntax.  An
728    "absolute-path" rule is defined for protocol elements that can
729    contain a non-empty path component.  (This rule differs slightly from
730    the path-abempty rule of RFC 3986, which allows for an empty path to
731    be used in references, and path-absolute rule, which does not allow
732    paths that begin with "//".)  A "partial-URI" rule is defined for
733    protocol elements that can contain a relative URI but not a fragment
734    component.
735
736
737Section 2.7., paragraph 6:
738OLD:
739
740 2.7.1.  http URI scheme
741
742NEW:
743
744 2.7.1.  http URI Scheme
745
746
747Section 2.7., paragraph 7:
748OLD:
749
750    The "http" URI scheme is hereby defined for the purpose of minting
751    identifiers according to their association with the hierarchical
752    namespace governed by a potential HTTP origin server listening for
753    TCP ([RFC0793]) connections on a given port.
754
755NEW:
756
757    The "http" URI scheme is hereby defined for the purpose of minting
758    identifiers according to their association with the hierarchical
759    namespace governed by a potential HTTP origin server listening for
760    TCP ([RFC793]) connections on a given port.
761
762
763Section 2.7., paragraph 17:
764OLD:
765
766 2.7.2.  https URI scheme
767
768NEW:
769
770 2.7.2.  https URI Scheme
771
772
773Section 2.1, paragraph 0:
774OLD:
775
776    If the port is equal to the default port for a scheme, the normal
777    form is to omit the port subcomponent.  When not being used in
778    absolute form as the request target of an OPTIONS request, an empty
779    path component is equivalent to an absolute path of "/", so the
780    normal form is to provide a path of "/" instead.  The scheme and host
781    are case-insensitive and normally provided in lowercase; all other
782    components are compared in a case-sensitive manner.  Characters other
783    than those in the "reserved" set are equivalent to their percent-
784    encoded octets: the normal form is to not encode them (see Sections
785    2.1 and 2.2 of [RFC3986]).
786
787NEW:
788
789    If the port is equal to the default port for a scheme, the normal
790    form is to omit the port subcomponent.  When not being used in
791    absolute form as the request target of an OPTIONS request, an empty
792    path component is equivalent to an absolute path of "/", so the
793    normal form is to provide a path of "/" instead.  The scheme and host
794    are case insensitive and normally provided in lowercase; all other
795    components are compared in a case-sensitive manner.  Characters other
796    than those in the "reserved" set are equivalent to their percent-
797    encoded octets: the normal form is to not encode them (see Sections
798    2.1 and 2.2 of [RFC3986]).
799
800
801Section 3.1., paragraph 1:
802OLD:
803
804    An HTTP message can either be a request from client to server or a
805    response from server to client.  Syntactically, the two types of
806    message differ only in the start-line, which is either a request-line
807    (for requests) or a status-line (for responses), and in the algorithm
808    for determining the length of the message body (Section 3.3).
809
810NEW:
811
812    An HTTP message can be either a request from client to server or a
813    response from server to client.  Syntactically, the two types of
814    message differ only in the start-line, which is either a request-line
815    (for requests) or a status-line (for responses), and in the algorithm
816    for determining the length of the message body (Section 3.3).
817
818
819Section 3.1., paragraph 2:
820OLD:
821
822    In theory, a client could receive requests and a server could receive
823    responses, distinguishing them by their different start-line formats,
824    but in practice servers are implemented to only expect a request (a
825    response is interpreted as an unknown or invalid request method) and
826    clients are implemented to only expect a response.
827
828NEW:
829
830    In theory, a client could receive requests and a server could receive
831    responses, distinguishing them by their different start-line formats,
832    but, in practice, servers are implemented only to expect a request (a
833    response is interpreted as an unknown or invalid request method) and
834    clients are implemented to only expect a response.
835
836
837Section 3.1.1., paragraph 1:
838OLD:
839
840    A request-line begins with a method token, followed by a single space
841    (SP), the request-target, another single space (SP), the protocol
842    version, and ending with CRLF.
843
844NEW:
845
846    A request-line begins with a method token and is followed by a single
847    space (SP), the request-target, another single space (SP), the
848    protocol version, and ends with CRLF.
849
850
851Section 3.1.1., paragraph 3:
852OLD:
853
854    The method token indicates the request method to be performed on the
855    target resource.  The request method is case-sensitive.
856
857NEW:
858
859    The method token indicates the request method to be performed on the
860    target resource.  The request method is case sensitive.
861
862
863Section 400, paragraph 1:
864OLD:
865
866    HTTP does not place a pre-defined limit on the length of a request-
867    line, as described in Section 2.5.  A server that receives a method
868    longer than any that it implements SHOULD respond with a 501 (Not
869    Implemented) status code.  A server that receives a request-target
870    longer than any URI it wishes to parse MUST respond with a 414 (URI
871    Too Long) status code (see Section 6.5.12 of [RFC7231]).
872
873NEW:
874
875    HTTP does not place a predefined limit on the length of a request-
876    line, as described in Section 2.5.  A server that receives a method
877    longer than any that it implements SHOULD respond with a 501 (Not
878    Implemented) status code.  A server that receives a request-target
879    longer than any URI it wishes to parse MUST respond with a 414 (URI
880    Too Long) status code (see Section 6.5.12 of [RFC7231]).
881
882
883Section 400, paragraph 2:
884OLD:
885
886    Various ad-hoc limitations on request-line length are found in
887    practice.  It is RECOMMENDED that all HTTP senders and recipients
888    support, at a minimum, request-line lengths of 8000 octets.
889
890NEW:
891
892    Various ad hoc limitations on request-line length are found in
893    practice.  It is RECOMMENDED that all HTTP senders and recipients
894    support, at a minimum, request-line lengths of 8000 octets.
895
896
897Section 3.1.2., paragraph 1:
898OLD:
899
900    The first line of a response message is the status-line, consisting
901    of the protocol version, a space (SP), the status code, another
902    space, a possibly-empty textual phrase describing the status code,
903    and ending with CRLF.
904
905NEW:
906
907    The first line of a response message is the status-line, consisting
908    of the protocol version, a space (SP), the status code, another space
909    (SP), a possibly empty textual phrase describing the status code,
910    and, finally, CRLF.
911
912
913Section 3.2.1., paragraph 4:
914OLD:
915
916    All defined header fields ought to be registered with IANA in the
917    Message Header Field Registry, as described in Section 8.3 of
918    [RFC7231].
919
920NEW:
921
922    All defined header fields ought to be registered with IANA in the
923    "Message Headers" field registry, as described in Section 8.3 of
924    [RFC7231].
925
926
927Section 3.2.2., paragraph 4:
928OLD:
929
930       Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
931       appears multiple times in a response message and does not use the
932       list syntax, violating the above requirements on multiple header
933       fields with the same name.  Since it cannot be combined into a
934       single field-value, recipients ought to handle "Set-Cookie" as a
935       special case while processing header fields.  (See Appendix A.2.3
936       of [Kri2001] for details.)
937
938NEW:
939
940       Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
941       appears multiple times in a response message and does not use the
942       list syntax, violating the above requirements on multiple header
943       fields with the same name.  Since it cannot be combined into a
944       single field-value, recipients ought to handle Set-Cookie as a
945       special case while processing header fields.  (See Appendix A.2.3
946       of [Kri2001] for details.)
947
948
949Section 3.2.3., paragraph 2:
950OLD:
951
952    The OWS rule is used where zero or more linear whitespace octets
953    might appear.  For protocol elements where optional whitespace is
954    preferred to improve readability, a sender SHOULD generate the
955    optional whitespace as a single SP; otherwise, a sender SHOULD NOT
956    generate optional whitespace except as needed to white-out invalid or
957    unwanted protocol elements during in-place message filtering.
958
959NEW:
960
961    The OWS rule is used where zero or more linear whitespace octets
962    might appear.  For protocol elements where optional whitespace is
963    preferred to improve readability, a sender SHOULD generate the
964    optional whitespace as a single SP; otherwise, a sender SHOULD NOT
965    generate optional whitespace except as needed to white out invalid or
966    unwanted protocol elements during in-place message filtering.
967
968
969Section 3.2.4., paragraph 1:
970OLD:
971
972    Messages are parsed using a generic algorithm, independent of the
973    individual header field names.  The contents within a given field
974    value are not parsed until a later stage of message interpretation
975    (usually after the message's entire header section has been
976    processed).  Consequently, this specification does not use ABNF rules
977    to define each "Field-Name: Field Value" pair, as was done in
978    previous editions.  Instead, this specification uses ABNF rules which
979    are named according to each registered field name, wherein the rule
980    defines the valid grammar for that field's corresponding field values
981    (i.e., after the field-value has been extracted from the header
982    section by a generic field parser).
983
984NEW:
985
986    Messages are parsed using a generic algorithm, independent of the
987    individual header field names.  The contents within a given field
988    value are not parsed until a later stage of message interpretation
989    (usually after the message's entire header section has been
990    processed).  Consequently, this specification does not use ABNF rules
991    to define each "field-name: field-value" pair, as was done in
992    previous editions.  Instead, this specification uses ABNF rules that
993    are named according to each registered field name, wherein the rule
994    defines the valid grammar for that field's corresponding field values
995    (i.e., after the field-value has been extracted from the header
996    section by a generic field parser).
997
998
999Section 3.2.4., paragraph 8:
1000OLD:
1001
1002    Historically, HTTP has allowed field content with text in the ISO-
1003    8859-1 [ISO-8859-1] charset, supporting other charsets only through
1004    use of [RFC2047] encoding.  In practice, most HTTP header field
1005    values use only a subset of the US-ASCII charset [USASCII].  Newly
1006    defined header fields SHOULD limit their field values to US-ASCII
1007    octets.  A recipient SHOULD treat other octets in field content (obs-
1008    text) as opaque data.
1009
1010NEW:
1011
1012    Historically, HTTP has allowed field content with text in the
1013    ISO-8859-1 [ISO-8859-1] charset, supporting other charsets only
1014    through use of [RFC2047] encoding.  In practice, most HTTP header
1015    field values use only a subset of the US-ASCII charset [USASCII].
1016    Newly defined header fields SHOULD limit their field values to
1017    US-ASCII octets.  A recipient SHOULD treat other octets in field
1018    content (obs-text) as opaque data.
1019
1020
1021Section 3.2.5., paragraph 1:
1022OLD:
1023
1024    HTTP does not place a pre-defined limit on the length of each header
1025    field or on the length of the header section as a whole, as described
1026    in Section 2.5.  Various ad-hoc limitations on individual header
1027    field length are found in practice, often depending on the specific
1028    field semantics.
1029
1030NEW:
1031
1032    HTTP does not place a predefined limit on the length of each header
1033    field or on the length of the header section as a whole, as described
1034    in Section 2.5.  Various ad hoc limitations on individual header
1035    field length are found in practice, often depending on the specific
1036    field semantics.
1037
1038
1039Section 3.2.5., paragraph 4:
1040OLD:
1041
1042 3.2.6.  Field value components
1043
1044NEW:
1045
1046 3.2.6.  Field Value Components
1047
1048
1049Section 7., paragraph 1:
1050OLD:
1051
1052    Since there is no way to distinguish a successfully completed, close-
1053    delimited message from a partially-received message interrupted by
1054    network failure, a server SHOULD generate encoding or length-
1055    delimited messages whenever possible.  The close-delimiting feature
1056    exists primarily for backwards compatibility with HTTP/1.0.
1057
1058NEW:
1059
1060    Since there is no way to distinguish a successfully completed, close-
1061    delimited message from a partially received message interrupted by
1062    network failure, a server SHOULD generate encoding or length-
1063    delimited messages whenever possible.  The close-delimiting feature
1064    exists primarily for backwards compatibility with HTTP/1.0.
1065
1066
1067Section 3.4., paragraph 1:
1068OLD:
1069
1070    A server that receives an incomplete request message, usually due to
1071    a canceled request or a triggered time-out exception, MAY send an
1072    error response prior to closing the connection.
1073
1074NEW:
1075
1076    A server that receives an incomplete request message, usually due to
1077    a canceled request or a triggered timeout exception, MAY send an
1078    error response prior to closing the connection.
1079
1080
1081Section 3.4., paragraph 4:
1082OLD:
1083
1084    A message body that uses the chunked transfer coding is incomplete if
1085    the zero-sized chunk that terminates the encoding has not been
1086    received.  A message that uses a valid Content-Length is incomplete
1087    if the size of the message body received (in octets) is less than the
1088    value given by Content-Length.  A response that has neither chunked
1089    transfer coding nor Content-Length is terminated by closure of the
1090    connection, and thus is considered complete regardless of the number
1091    of message body octets received, provided that the header section was
1092    received intact.
1093
1094NEW:
1095
1096    A message body that uses the chunked transfer coding is incomplete if
1097    the zero-sized chunk that terminates the encoding has not been
1098    received.  A message that uses a valid Content-Length is incomplete
1099    if the size of the message body received (in octets) is less than the
1100    value given by Content-Length.  A response that has neither chunked
1101    transfer coding nor Content-Length is terminated by closure of the
1102    connection and, thus, is considered complete regardless of the number
1103    of message body octets received, provided that the header section was
1104    received intact.
1105
1106
1107Section 4., paragraph 5:
1108OLD:
1109
1110    All transfer-coding names are case-insensitive and ought to be
1111    registered within the HTTP Transfer Coding registry, as defined in
1112    Section 8.4.  They are used in the TE (Section 4.3) and Transfer-
1113    Encoding (Section 3.3.1) header fields.
1114
1115NEW:
1116
1117    All transfer-coding names are case insensitive and ought to be
1118    registered within the "HTTP Transfer Coding" registry, as defined in
1119    Section 8.4.  They are used in the TE (Section 4.3) and Transfer-
1120    Encoding (Section 3.3.1) header fields.
1121
1122
1123Section 4.2.3., paragraph 1:
1124OLD:
1125
1126    The "gzip" coding is an LZ77 coding with a 32 bit CRC that is
1127    commonly produced by the gzip file compression program [RFC1952].  A
1128    recipient SHOULD consider "x-gzip" to be equivalent to "gzip".
1129
1130NEW:
1131
1132    The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy
1133    Check (CRC) that is commonly produced by the gzip file compression
1134    program [RFC1952].  A recipient SHOULD consider "x-gzip" to be
1135    equivalent to "gzip".
1136
1137
1138Section 5.7.1., paragraph 8:
1139OLD:
1140
1141    A sender MAY generate comments in the Via header field to identify
1142    the software of each recipient, analogous to the User-Agent and
1143    Server header fields.  However, all comments in the Via field are
1144    optional and a recipient MAY remove them prior to forwarding the
1145    message.
1146
1147NEW:
1148
1149    A sender MAY generate comments in the Via header field to identify
1150    the software of each recipient, analogous to the User-Agent and
1151    Server header fields.  However, all comments in the Via field are
1152    optional, and a recipient MAY remove them prior to forwarding the
1153    message.
1154
1155
1156Section 5.7.2., paragraph 6:
1157OLD:
1158
1159    A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of
1160    a message that contains a no-transform cache-control directive
1161    (Section 5.2 of [RFC7234]).
1162
1163NEW:
1164
1165    A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of
1166    a message that contains a no-transform Cache-Control directive
1167    (Section 5.2 of [RFC7234]).
1168
1169
1170Section 200, paragraph 0:
1171OLD:
1172
1173    A proxy MAY transform the payload of a message that does not contain
1174    a no-transform cache-control directive.  A proxy that transforms a
1175    payload MUST add a Warning header field with the warn-code of 214
1176    ("Transformation Applied") if one is not already in the message (see
1177    Section 5.5 of [RFC7234]).  A proxy that transforms the payload of a
1178    200 (OK) response can further inform downstream recipients that a
1179    transformation has been applied by changing the response status code
1180    to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).
1181
1182NEW:
1183
1184    A proxy MAY transform the payload of a message that does not contain
1185    a no-transform Cache-Control directive.  A proxy that transforms a
1186    payload MUST add a Warning header field with the warn-code of 214
1187    ("Transformation Applied") if one is not already in the message (see
1188    Section 5.5 of [RFC7234]).  A proxy that transforms the payload of a
1189    200 (OK) response can further inform downstream recipients that a
1190    transformation has been applied by changing the response status code
1191    to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).
1192
1193
1194Section 6., paragraph 1:
1195OLD:
1196
1197    HTTP messaging is independent of the underlying transport or session-
1198    layer connection protocol(s).  HTTP only presumes a reliable
1199    transport with in-order delivery of requests and the corresponding
1200    in-order delivery of responses.  The mapping of HTTP request and
1201    response structures onto the data units of an underlying transport
1202    protocol is outside the scope of this specification.
1203
1204NEW:
1205
1206    HTTP messaging is independent of the underlying transport- or
1207    session-layer connection protocol(s).  HTTP only presumes a reliable
1208    transport with in-order delivery of requests and the corresponding
1209    in-order delivery of responses.  The mapping of HTTP request and
1210    response structures onto the data units of an underlying transport
1211    protocol is outside the scope of this specification.
1212
1213
1214Section 6., paragraph 3:
1215OLD:
1216
1217    HTTP implementations are expected to engage in connection management,
1218    which includes maintaining the state of current connections,
1219    establishing a new connection or reusing an existing connection,
1220    processing messages received on a connection, detecting connection
1221    failures, and closing each connection.  Most clients maintain
1222    multiple connections in parallel, including more than one connection
1223    per server endpoint.  Most servers are designed to maintain thousands
1224    of concurrent connections, while controlling request queues to enable
1225    fair use and detect denial of service attacks.
1226
1227NEW:
1228
1229    HTTP implementations are expected to engage in connection management,
1230    which includes maintaining the state of current connections,
1231    establishing a new connection or reusing an existing connection,
1232    processing messages received on a connection, detecting connection
1233    failures, and closing each connection.  Most clients maintain
1234    multiple connections in parallel, including more than one connection
1235    per server endpoint.  Most servers are designed to maintain thousands
1236    of concurrent connections, while controlling request queues to enable
1237    fair use and detect denial-of-service attacks.
1238
1239
1240Section 6.1., paragraph 6:
1241OLD:
1242
1243    Connection options are case-insensitive.
1244
1245NEW:
1246
1247    Connection options are case insensitive.
1248
1249
1250Section 6.2., paragraph 1:
1251OLD:
1252
1253    It is beyond the scope of this specification to describe how
1254    connections are established via various transport or session-layer
1255    protocols.  Each connection applies to only one transport link.
1256
1257NEW:
1258
1259    It is beyond the scope of this specification to describe how
1260    connections are established via various transport- or session-layer
1261    protocols.  Each connection applies to only one transport link.
1262
1263
1264Section 6.3., paragraph 1:
1265OLD:
1266
1267    HTTP/1.1 defaults to the use of "persistent connections", allowing
1268    multiple requests and responses to be carried over a single
1269    connection.  The "close" connection-option is used to signal that a
1270    connection will not persist after the current request/response.  HTTP
1271    implementations SHOULD support persistent connections.
1272
1273NEW:
1274
1275    HTTP/1.1 defaults to the use of "persistent connections", allowing
1276    multiple requests and responses to be carried over a single
1277    connection.  The "close" connection option is used to signal that a
1278    connection will not persist after the current request/response.  HTTP
1279    implementations SHOULD support persistent connections.
1280
1281
1282Section 6.3., paragraph 3:
1283OLD:
1284
1285    o  If the close connection option is present, the connection will not
1286       persist after the current response; else,
1287
1288NEW:
1289
1290    o  If the "close" connection option is present, the connection will
1291       not persist after the current response; else,
1292
1293
1294Section 6.3., paragraph 7:
1295OLD:
1296
1297    A client MAY send additional requests on a persistent connection
1298    until it sends or receives a close connection option or receives an
1299    HTTP/1.0 response without a "keep-alive" connection option.
1300
1301NEW:
1302
1303    A client MAY send additional requests on a persistent connection
1304    until it sends or receives a "close" connection option or receives an
1305    HTTP/1.0 response without a "keep-alive" connection option.
1306
1307
1308Section 6.3., paragraph 10:
1309OLD:
1310
1311    See Appendix A.1.2 for more information on backward compatibility
1312    with HTTP/1.0 clients.
1313
1314NEW:
1315
1316    See Appendix A.1.2 for more information on backwards compatibility
1317    with HTTP/1.0 clients.
1318
1319
1320Section 6.3.2., paragraph 1:
1321OLD:
1322
1323    A client that supports persistent connections MAY "pipeline" its
1324    requests (i.e., send multiple requests without waiting for each
1325    response).  A server MAY process a sequence of pipelined requests in
1326    parallel if they all have safe methods (Section 4.2.1 of [RFC7231]),
1327    but MUST send the corresponding responses in the same order that the
1328    requests were received.
1329
1330NEW:
1331
1332    A client that supports persistent connections MAY "pipeline" its
1333    requests (i.e., send multiple requests without waiting for each
1334    response).  A server MAY process a sequence of pipelined requests in
1335    parallel if they all have safe methods (Section 4.2.1 of [RFC7231]),
1336    but it MUST send the corresponding responses in the same order that
1337    the requests were received.
1338
1339
1340Section 6.4., paragraph 2:
1341OLD:
1342
1343    Previous revisions of HTTP gave a specific number of connections as a
1344    ceiling, but this was found to be impractical for many applications.
1345    As a result, this specification does not mandate a particular maximum
1346    number of connections, but instead encourages clients to be
1347    conservative when opening multiple connections.
1348
1349NEW:
1350
1351    Previous revisions of HTTP gave a specific number of connections as a
1352    ceiling, but this was found to be impractical for many applications.
1353    As a result, this specification does not mandate a particular maximum
1354    number of connections but, instead, encourages clients to be
1355    conservative when opening multiple connections.
1356
1357
1358Section 6.4., paragraph 4:
1359OLD:
1360
1361    Note that a server might reject traffic that it deems abusive or
1362    characteristic of a denial of service attack, such as an excessive
1363    number of open connections from a single client.
1364
1365NEW:
1366
1367    Note that a server might reject traffic that it deems abusive or
1368    characteristic of a denial-of-service attack, such as an excessive
1369    number of open connections from a single client.
1370
1371
1372Section 6.4., paragraph 5:
1373OLD:
1374
1375 6.5.  Failures and Time-outs
1376
1377NEW:
1378
1379 6.5.  Failures and Timeouts
1380
1381
1382Section 6.4., paragraph 6:
1383OLD:
1384
1385    Servers will usually have some time-out value beyond which they will
1386    no longer maintain an inactive connection.  Proxy servers might make
1387    this a higher value since it is likely that the client will be making
1388    more connections through the same proxy server.  The use of
1389    persistent connections places no requirements on the length (or
1390    existence) of this time-out for either the client or the server.
1391
1392NEW:
1393
1394    Servers will usually have some timeout value beyond which they will
1395    no longer maintain an inactive connection.  Proxy servers might make
1396    this a higher value since it is likely that the client will be making
1397    more connections through the same proxy server.  The use of
1398    persistent connections places no requirements on the length (or
1399    existence) of this timeout for either the client or the server.
1400
1401
1402Section 6.4., paragraph 7:
1403OLD:
1404
1405    A client or server that wishes to time-out SHOULD issue a graceful
1406    close on the connection.  Implementations SHOULD constantly monitor
1407    open connections for a received closure signal and respond to it as
1408    appropriate, since prompt closure of both sides of a connection
1409    enables allocated system resources to be reclaimed.
1410
1411NEW:
1412
1413    A client or server that wishes to time out SHOULD issue a graceful
1414    close on the connection.  Implementations SHOULD constantly monitor
1415    open connections for a received closure signal and respond to it as
1416    appropriate, since prompt closure of both sides of a connection
1417    enables allocated system resources to be reclaimed.
1418
1419
1420Section 6.4., paragraph 9:
1421OLD:
1422
1423    A server SHOULD sustain persistent connections, when possible, and
1424    allow the underlying transport's flow control mechanisms to resolve
1425    temporary overloads, rather than terminate connections with the
1426    expectation that clients will retry.  The latter technique can
1427    exacerbate network congestion.
1428
1429NEW:
1430
1431    A server SHOULD sustain persistent connections, when possible, and
1432    allow the underlying transport's flow-control mechanisms to resolve
1433    temporary overloads, rather than terminate connections with the
1434    expectation that clients will retry.  The latter technique can
1435    exacerbate network congestion.
1436
1437
1438Section 6.4., paragraph 11:
1439OLD:
1440
1441 6.6.  Tear-down
1442
1443NEW:
1444
1445 6.6.  Teardown
1446
1447
1448Section 6.4., paragraph 13:
1449OLD:
1450
1451    A client that sends a close connection option MUST NOT send further
1452    requests on that connection (after the one containing close) and MUST
1453    close the connection after reading the final response message
1454    corresponding to this request.
1455
1456NEW:
1457
1458    A client that sends a "close" connection option MUST NOT send further
1459    requests on that connection (after the one containing close) and MUST
1460    close the connection after reading the final response message
1461    corresponding to this request.
1462
1463
1464Section 6.4., paragraph 14:
1465OLD:
1466
1467    A server that receives a close connection option MUST initiate a
1468    close of the connection (see below) after it sends the final response
1469    to the request that contained close.  The server SHOULD send a close
1470    connection option in its final response on that connection.  The
1471    server MUST NOT process any further requests received on that
1472    connection.
1473
1474NEW:
1475
1476    A server that receives a "close" connection option MUST initiate a
1477    close of the connection (see below) after it sends the final response
1478    to the request that contained close.  The server SHOULD send a close
1479    connection option in its final response on that connection.  The
1480    server MUST NOT process any further requests received on that
1481    connection.
1482
1483
1484Section 6.4., paragraph 15:
1485OLD:
1486
1487    A server that sends a close connection option MUST initiate a close
1488    of the connection (see below) after it sends the response containing
1489    close.  The server MUST NOT process any further requests received on
1490    that connection.
1491
1492NEW:
1493
1494    A server that sends a "close" connection option MUST initiate a close
1495    of the connection (see below) after it sends the response containing
1496    close.  The server MUST NOT process any further requests received on
1497    that connection.
1498
1499
1500Section 6.4., paragraph 16:
1501OLD:
1502
1503    A client that receives a close connection option MUST cease sending
1504    requests on that connection and close the connection after reading
1505    the response message containing the close; if additional pipelined
1506    requests had been sent on the connection, the client SHOULD NOT
1507    assume that they will be processed by the server.
1508
1509NEW:
1510
1511    A client that receives a "close" connection option MUST cease sending
1512    requests on that connection and close the connection after reading
1513    the response message containing the close; if additional pipelined
1514    requests had been sent on the connection, the client SHOULD NOT
1515    assume that they will be processed by the server.
1516
1517
1518Section 6.4., paragraph 17:
1519OLD:
1520
1521    If a server performs an immediate close of a TCP connection, there is
1522    a significant risk that the client will not be able to read the last
1523    HTTP response.  If the server receives additional data from the
1524    client on a fully-closed connection, such as another request that was
1525    sent by the client before receiving the server's response, the
1526    server's TCP stack will send a reset packet to the client;
1527    unfortunately, the reset packet might erase the client's
1528    unacknowledged input buffers before they can be read and interpreted
1529    by the client's HTTP parser.
1530
1531NEW:
1532
1533    If a server performs an immediate close of a TCP connection, there is
1534    a significant risk that the client will not be able to read the last
1535    HTTP response.  If the server receives additional data from the
1536    client on a fully closed connection, such as another request that was
1537    sent by the client before receiving the server's response, the
1538    server's TCP stack will send a reset packet to the client;
1539    unfortunately, the reset packet might erase the client's
1540    unacknowledged input buffers before they can be read and interpreted
1541    by the client's HTTP parser.
1542
1543
1544Section 6.7., paragraph 9:
1545OLD:
1546
1547    The capabilities and nature of the application-level communication
1548    after the protocol change is entirely dependent upon the new
1549    protocol(s) chosen.  However, immediately after sending the 101
1550    response, the server is expected to continue responding to the
1551    original request as if it had received its equivalent within the new
1552    protocol (i.e., the server still has an outstanding request to
1553    satisfy after the protocol has been changed, and is expected to do so
1554    without requiring the request to be repeated).
1555
1556NEW:
1557
1558    The capabilities and nature of the application-level communication
1559    after the protocol change is entirely dependent upon the new
1560    protocol(s) chosen.  However, immediately after sending the 101
1561    (Switching Protocols) response, the server is expected to continue
1562    responding to the original request as if it had received its
1563    equivalent within the new protocol (i.e., the server still has an
1564    outstanding request to satisfy after the protocol has been changed,
1565    and is expected to do so without requiring the request to be
1566    repeated).
1567
1568
1569Section 101, paragraph 0:
1570OLD:
1571
1572    For example, if the Upgrade header field is received in a GET request
1573    and the server decides to switch protocols, it first responds with a
1574    101 (Switching Protocols) message in HTTP/1.1 and then immediately
1575    follows that with the new protocol's equivalent of a response to a
1576    GET on the target resource.  This allows a connection to be upgraded
1577    to protocols with the same semantics as HTTP without the latency cost
1578    of an additional round-trip.  A server MUST NOT switch protocols
1579    unless the received message semantics can be honored by the new
1580    protocol; an OPTIONS request can be honored by any protocol.
1581
1582NEW:
1583
1584    For example, if the Upgrade header field is received in a GET request
1585    and the server decides to switch protocols, it first responds with a
1586    101 (Switching Protocols) message in HTTP/1.1 and then immediately
1587    follows that with the new protocol's equivalent of a response to a
1588    GET on the target resource.  This allows a connection to be upgraded
1589    to protocols with the same semantics as HTTP without the latency cost
1590    of an additional round trip.  A server MUST NOT switch protocols
1591    unless the received message semantics can be honored by the new
1592    protocol; an OPTIONS request can be honored by any protocol.
1593
1594
1595Section 101, paragraph 5:
1596OLD:
1597
1598    A client cannot begin using an upgraded protocol on the connection
1599    until it has completely sent the request message (i.e., the client
1600    can't change the protocol it is sending in the middle of a message).
1601    If a server receives both Upgrade and an Expect header field with the
1602    "100-continue" expectation (Section 5.1.1 of [RFC7231]), the server
1603    MUST send a 100 (Continue) response before sending a 101 (Switching
1604    Protocols) response.
1605
1606NEW:
1607
1608    A client cannot begin using an upgraded protocol on the connection
1609    until it has completely sent the request message (i.e., the client
1610    can't change the protocol it is sending in the middle of a message).
1611    If a server receives both an Upgrade and an Expect header field with
1612    the "100-continue" expectation (Section 5.1.1 of [RFC7231]), the
1613    server MUST send a 100 (Continue) response before sending a 101
1614    (Switching Protocols) response.
1615
1616
1617Section 101, paragraph 8:
1618OLD:
1619
1620 7.  ABNF list extension: #rule
1621
1622NEW:
1623
1624 7.  ABNF List Extension: #rule
1625
1626
1627Section 101, paragraph 17:
1628OLD:
1629
1630    For compatibility with legacy list rules, a recipient MUST parse and
1631    ignore a reasonable number of empty list elements: enough to handle
1632    common mistakes by senders that merge values, but not so much that
1633    they could be used as a denial of service mechanism.  In other words,
1634    a recipient MUST accept lists that satisfy the following syntax:
1635
1636NEW:
1637
1638    For compatibility with legacy list rules, a recipient MUST parse and
1639    ignore a reasonable number of empty list elements: enough to handle
1640    common mistakes by senders that merge values, but not so much that
1641    they could be used as a denial-of-service mechanism.  In other words,
1642    a recipient MUST accept lists that satisfy the following syntax:
1643
1644
1645Section 101, paragraph 22:
1646OLD:
1647
1648    Then the following are valid values for example-list (not including
1649    the double quotes, which are present for delimitation only):
1650
1651NEW:
1652
1653    Then, the following are valid values for example-list (not including
1654    the double quotes, which are present for delimitation only):
1655
1656
1657Section 8.1., paragraph 1:
1658OLD:
1659
1660    HTTP header fields are registered within the Message Header Field
1661    Registry maintained at
1662    <http://www.iana.org/assignments/message-headers/>.
1663
1664NEW:
1665
1666    HTTP header fields are registered within the "Message Header" field
1667    registry maintained at
1668    <http://www.iana.org/assignments/message-headers/>.
1669
1670
1671Section 8.1., paragraph 2:
1672OLD:
1673
1674    This document defines the following HTTP header fields, so their
1675    associated registry entries shall be updated according to the
1676    permanent registrations below (see [BCP90]):
1677
1678NEW:
1679
1680    This document defines the following HTTP header fields, so the
1681    "Permanent Message Header Field Names" registry has been updated
1682    accordingly (see [BCP90]).
1683
1684
1685Section 8.1., paragraph 4:
1686OLD:
1687
1688    Furthermore, the header field-name "Close" shall be registered as
1689    "reserved", since using that name as an HTTP header field might
1690    conflict with the "close" connection option of the "Connection"
1691    header field (Section 6.1).
1692
1693NEW:
1694
1695    Furthermore, the header field-name "Close" has been registered as
1696    "reserved", since using that name as an HTTP header field might
1697    conflict with the "close" connection option of the "Connection"
1698    header field (Section 6.1).
1699
1700
1701Section 8.2., paragraph 2:
1702OLD:
1703
1704    This document defines the following URI schemes, so their associated
1705    registry entries shall be updated according to the permanent
1706    registrations below:
1707
1708NEW:
1709
1710    This document defines the following URI schemes, so the "Permanent
1711    URI Schemes" registry has been updated accordingly.
1712
1713
1714Section 8.3., paragraph 2:
1715OLD:
1716
1717    This document serves as the specification for the Internet media
1718    types "message/http" and "application/http".  The following is to be
1719    registered with IANA.
1720
1721NEW:
1722
1723    This document serves as the specification for the Internet media
1724    types "message/http" and "application/http".  The following has been
1725    registered with IANA.
1726
1727
1728Section 8.3.1., paragraph 18:
1729OLD:
1730
1731    Person and email address to contact for further information:  See
1732       Authors Section.
1733
1734NEW:
1735
1736    Person and email address to contact for further information:
1737       See Authors' Addresses  Section.
1738
1739
1740Section 8.3.1., paragraph 21:
1741OLD:
1742
1743    Author:  See Authors Section.
1744
1745NEW:
1746
1747    Author:  See Authors' Addresses Section.
1748
1749
1750Section 8.3.2., paragraph 8:
1751OLD:
1752
1753    Encoding considerations:  HTTP messages enclosed by this type are in
1754       "binary" format; use of an appropriate Content-Transfer-Encoding
1755       is required when transmitted via E-mail.
1756
1757NEW:
1758
1759    Encoding considerations:  HTTP messages enclosed by this type are in
1760       "binary" format; use of an appropriate Content-Transfer-Encoding
1761       is required when transmitted via email.
1762
1763
1764Section 8.3.2., paragraph 19:
1765OLD:
1766
1767    Person and email address to contact for further information:  See
1768       Authors Section.
1769
1770NEW:
1771
1772    Person and email address to contact for further information:
1773       See Authors' Addresses Section.
1774
1775
1776Section 8.3.2., paragraph 22:
1777OLD:
1778
1779    Author:  See Authors Section.
1780
1781NEW:
1782
1783    Author:  See Authors' Addresses Section.
1784
1785
1786Section 8.4., paragraph 1:
1787OLD:
1788
1789    The HTTP Transfer Coding Registry defines the name space for transfer
1790    coding names.  It is maintained at
1791    <http://www.iana.org/assignments/http-parameters>.
1792
1793NEW:
1794
1795    The "HTTP Transfer Coding" registry defines the namespace for
1796    transfer coding names.  It is maintained at
1797    <http://www.iana.org/assignments/http-parameters>.
1798
1799
1800Section 8.4.1., paragraph 5:
1801OLD:
1802
1803    Values to be added to this name space require IETF Review (see
1804    Section 4.1 of [RFC5226]), and MUST conform to the purpose of
1805    transfer coding defined in this specification.
1806
1807NEW:
1808
1809    Values to be added to this namespace require IETF Review (see Section
1810    4.1 of [RFC5226]), and MUST conform to the purpose of transfer coding
1811    defined in this specification.
1812
1813
1814Section 8.4.2., paragraph 1:
1815OLD:
1816
1817    The HTTP Transfer Coding Registry shall be updated with the
1818    registrations below:
1819
1820NEW:
1821
1822    The "HTTP Transfer Coding Registry" has been updated with the
1823    registrations below:
1824
1825
1826Section 8.5., paragraph 1:
1827OLD:
1828
1829    IANA maintains the registry of HTTP Content Codings at
1830    <http://www.iana.org/assignments/http-parameters>.
1831
1832NEW:
1833
1834    IANA maintains the "HTTP Content Coding Registry" at
1835    <http://www.iana.org/assignments/http-parameters>.
1836
1837
1838Section 8.5., paragraph 2:
1839OLD:
1840
1841    The HTTP Content Codings Registry shall be updated with the
1842    registrations below:
1843
1844NEW:
1845
1846    The "HTTP Content Codings Registry" has been updated with the
1847    registrations below:
1848
1849
1850Section 8.6., paragraph 1:
1851OLD:
1852
1853    The HTTP Upgrade Token Registry defines the name space for protocol-
1854    name tokens used to identify protocols in the Upgrade header field.
1855    The registry is maintained at
1856    <http://www.iana.org/assignments/http-upgrade-tokens>.
1857
1858NEW:
1859
1860    The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
1861    defines the namespace for protocol-name tokens used to identify
1862    protocols in the Upgrade header field.  The registry is maintained at
1863    <http://www.iana.org/assignments/http-upgrade-tokens>.
1864
1865
1866Section 8.6.2., paragraph 1:
1867OLD:
1868
1869    The "HTTP" entry in the HTTP Upgrade Token Registry shall be updated
1870    with the registration below:
1871
1872NEW:
1873
1874    The "HTTP" entry in the "HTTP Upgrade Token" registry shall be
1875    updated with the registration below:
1876
1877
1878Section 9.1., paragraph 3:
1879OLD:
1880
1881    When a registered name is used in the authority component, the "http"
1882    URI scheme (Section 2.7.1) relies on the user's local name resolution
1883    service to determine where it can find authoritative responses.  This
1884    means that any attack on a user's network host table, cached names,
1885    or name resolution libraries becomes an avenue for attack on
1886    establishing authority.  Likewise, the user's choice of server for
1887    Domain Name Service (DNS), and the hierarchy of servers from which it
1888    obtains resolution results, could impact the authenticity of address
1889    mappings; DNSSEC ([RFC4033]) is one way to improve authenticity.
1890
1891NEW:
1892
1893    When a registered name is used in the authority component, the "http"
1894    URI scheme (Section 2.7.1) relies on the user's local name resolution
1895    service to determine where it can find authoritative responses.  This
1896    means that any attack on a user's network host table, cached names,
1897    or name resolution libraries becomes an avenue for attack on
1898    establishing authority.  Likewise, the user's choice of server for
1899    Domain Name Service (DNS), and the hierarchy of servers from which it
1900    obtains resolution results, could impact the authenticity of address
1901    mappings; DNS Security Extensions (DNSSEC) ([RFC4033]) is one way to
1902    improve authenticity.
1903
1904
1905Section 9.2., paragraph 1:
1906OLD:
1907
1908    By their very nature, HTTP intermediaries are men-in-the-middle, and
1909    thus represent an opportunity for man-in-the-middle attacks.
1910    Compromise of the systems on which the intermediaries run can result
1911    in serious security and privacy problems.  Intermediaries might have
1912    access to security-related information, personal information about
1913    individual users and organizations, and proprietary information
1914    belonging to users and content providers.  A compromised
1915    intermediary, or an intermediary implemented or configured without
1916    regard to security and privacy considerations, might be used in the
1917    commission of a wide range of potential attacks.
1918
1919NEW:
1920
1921    By their very nature, HTTP intermediaries are men in the middle and,
1922    thus, represent an opportunity for man-in-the-middle attacks.
1923    Compromise of the systems on which the intermediaries run can result
1924    in serious security and privacy problems.  Intermediaries might have
1925    access to security-related information, personal information about
1926    individual users and organizations, and proprietary information
1927    belonging to users and content providers.  A compromised
1928    intermediary, or an intermediary implemented or configured without
1929    regard to security and privacy considerations, might be used in the
1930    commission of a wide range of potential attacks.
1931
1932
1933Section 9.3., paragraph 4:
1934OLD:
1935
1936    Recipients ought to carefully limit the extent to which they process
1937    other protocol elements, including (but not limited to) request
1938    methods, response status phrases, header field-names, numeric values,
1939    and body chunks.  Failure to limit such processing can result in
1940    buffer overflows, arithmetic overflows, or increased vulnerability to
1941    denial of service attacks.
1942
1943NEW:
1944
1945    Recipients ought to carefully limit the extent to which they process
1946    other protocol elements, including (but not limited to) request
1947    methods, response status phrases, header field-names, numeric values,
1948    and body chunks.  Failure to limit such processing can result in
1949    buffer overflows, arithmetic overflows, or increased vulnerability to
1950    denial-of-service attacks.
1951
1952
1953Section 9.6., paragraph 2:
1954OLD:
1955
1956    User agents are encouraged to implement configurable means for
1957    detecting and reporting failures of message integrity such that those
1958    means can be enabled within environments for which integrity is
1959    necessary.  For example, a browser being used to view medical history
1960    or drug interaction information needs to indicate to the user when
1961    such information is detected by the protocol to be incomplete,
1962    expired, or corrupted during transfer.  Such mechanisms might be
1963    selectively enabled via user agent extensions or the presence of
1964    message integrity metadata in a response.  At a minimum, user agents
1965    ought to provide some indication that allows a user to distinguish
1966    between a complete and incomplete response message (Section 3.4) when
1967    such verification is desired.
1968
1969NEW:
1970
1971    User agents are encouraged to implement configurable means for
1972    detecting and reporting failures of message integrity such that those
1973    means can be enabled within environments for which integrity is
1974    necessary.  For example, a browser being used to view medical history
1975    or drug interaction information needs to indicate to the user when
1976    such information is detected by the protocol to be incomplete,
1977    expired, or corrupted during transfer.  Such mechanisms might be
1978    selectively enabled via user-agent extensions or the presence of
1979    message integrity metadata in a response.  At a minimum, user agents
1980    ought to provide some indication that allows a user to distinguish
1981    between a complete and incomplete response message (Section 3.4) when
1982    such verification is desired.
1983
1984
1985Section 9.8., paragraph 2:
1986OLD:
1987
1988    HTTP log information is confidential in nature; its handling is often
1989    constrained by laws and regulations.  Log information needs to be
1990    securely stored and appropriate guidelines followed for its analysis.
1991    Anonymization of personal information within individual entries
1992    helps, but is generally not sufficient to prevent real log traces
1993    from being re-identified based on correlation with other access
1994    characteristics.  As such, access traces that are keyed to a specific
1995    client are unsafe to publish even if the key is pseudonymous.
1996
1997NEW:
1998
1999    HTTP log information is confidential in nature; its handling is often
2000    constrained by laws and regulations.  Log information needs to be
2001    securely stored and appropriate guidelines followed for its analysis.
2002    Anonymization of personal information within individual entries
2003    helps, but it is generally not sufficient to prevent real log traces
2004    from being re-identified based on correlation with other access
2005    characteristics.  As such, access traces that are keyed to a specific
2006    client are unsafe to publish even if the key is pseudonymous.
2007
2008
2009Section 10., paragraph 1:
2010OLD:
2011
2012    This edition of HTTP/1.1 builds on the many contributions that went
2013    into RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including
2014    substantial contributions made by the previous authors, editors, and
2015    working group chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding,
2016    Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter,
2017    and Paul J. Leach.  Mark Nottingham oversaw this effort as working
2018    group chair.
2019
2020NEW:
2021
2022    This edition of HTTP/1.1 builds on the many contributions that went
2023    into RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including
2024    substantial contributions made by the previous authors, editors, and
2025    Working Group Chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding,
2026    Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter,
2027    and Paul J. Leach.  Mark Nottingham oversaw this effort as Working
2028    Group Chair.
2029
2030
2031Section 11.1., paragraph 1:
2032OLD:
2033
2034    [RFC0793]     Postel, J., "Transmission Control Protocol", STD 7,
2035                  RFC 793, September 1981.
2036 
2037    [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
2038                  Format Specification version 3.3", RFC 1950, May 1996.
2039
2040NEW:
2041
2042    [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
2043                  Format Specification version 3.3", RFC 1950, May 1996.
2044
2045
2046Section 11.1., paragraph 7:
2047OLD:
2048
2049    [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
2050                  Transfer Protocol (HTTP/1.1): Semantics and Content",
2051                  draft-ietf-httpbis-p2-semantics-latest (work in
2052                  progress), May 2014.
2053
2054NEW:
2055
2056    [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
2057                  Transfer Protocol (HTTP/1.1): Semantics and Content",
2058                  RFC 7231, May 2014.
2059
2060
2061Section 11.1., paragraph 8:
2062OLD:
2063
2064    [RFC7232]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
2065                  Transfer Protocol (HTTP/1.1): Conditional Requests",
2066                  draft-ietf-httpbis-p4-conditional-latest (work in
2067                  progress), May 2014.
2068
2069NEW:
2070
2071    [RFC7232]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
2072                  Transfer Protocol (HTTP/1.1): Conditional Requests",
2073                  RFC 7232, May 2014.
2074
2075
2076Section 11.1., paragraph 9:
2077OLD:
2078
2079    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
2080                  "Hypertext Transfer Protocol (HTTP/1.1): Range
2081                  Requests", draft-ietf-httpbis-p5-range-latest (work in
2082                  progress), May 2014.
2083
2084NEW:
2085
2086    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
2087                  "Hypertext Transfer Protocol (HTTP/1.1): Range
2088                  Requests", RFC 7233, May 2014.
2089
2090
2091Section 11.1., paragraph 10:
2092OLD:
2093
2094    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
2095                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
2096                  draft-ietf-httpbis-p6-cache-latest (work in progress),
2097                  May 2014.
2098
2099NEW:
2100
2101    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
2102                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
2103                  RFC 7234, May 2014.
2104
2105
2106Section 11.1., paragraph 11:
2107OLD:
2108
2109    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
2110                  Transfer Protocol (HTTP/1.1): Authentication",
2111                  draft-ietf-httpbis-p7-auth-latest (work in progress),
2112                  May 2014.
2113
2114NEW:
2115
2116    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
2117                  Transfer Protocol (HTTP/1.1): Authentication",
2118                  RFC 7235, May 2014.
2119 
2120    [RFC793]      Postel, J., "Transmission Control Protocol", STD 7,
2121                  RFC 793, September 1981.
2122
2123
2124Section 11.1., paragraph 13:
2125OLD:
2126
2127    [Welch]       Welch, T., "A Technique for High Performance Data
2128                  Compression", IEEE Computer 17(6), June 1984.
2129
2130NEW:
2131
2132    [Welch]       Welch, T., "A Technique for High-Performance Data
2133                  Compression", IEEE Computer 17(6), June 1984.
2134
2135
2136Appendix A., paragraph 1:
2137OLD:
2138
2139    HTTP has been in use since 1990.  The first version, later referred
2140    to as HTTP/0.9, was a simple protocol for hypertext data transfer
2141    across the Internet, using only a single request method (GET) and no
2142    metadata.  HTTP/1.0, as defined by [RFC1945], added a range of
2143    request methods and MIME-like messaging, allowing for metadata to be
2144    transferred and modifiers placed on the request/response semantics.
2145    However, HTTP/1.0 did not sufficiently take into consideration the
2146    effects of hierarchical proxies, caching, the need for persistent
2147    connections, or name-based virtual hosts.  The proliferation of
2148    incompletely-implemented applications calling themselves "HTTP/1.0"
2149    further necessitated a protocol version change in order for two
2150    communicating applications to determine each other's true
2151    capabilities.
2152
2153NEW:
2154
2155    HTTP has been in use since 1990.  The first version, later referred
2156    to as HTTP/0.9, was a simple protocol for hypertext data transfer
2157    across the Internet, using only a single request method (GET) and no
2158    metadata.  HTTP/1.0, as defined by [RFC1945], added a range of
2159    request methods and MIME-like messaging, allowing for metadata to be
2160    transferred and modifiers placed on the request/response semantics.
2161    However, HTTP/1.0 did not sufficiently take into consideration the
2162    effects of hierarchical proxies, caching, the need for persistent
2163    connections, or name-based virtual hosts.  The proliferation of
2164    incompletely implemented applications calling themselves "HTTP/1.0"
2165    further necessitated a protocol version change in order for two
2166    communicating applications to determine each other's true
2167    capabilities.
2168
2169
2170Appendix A., paragraph 2:
2171OLD:
2172
2173    HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
2174    requirements that enable reliable implementations, adding only those
2175    features that can either be safely ignored by an HTTP/1.0 recipient
2176    or only sent when communicating with a party advertising conformance
2177    with HTTP/1.1.
2178
2179NEW:
2180
2181    HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
2182    requirements that enable reliable implementations, adding only those
2183    features that can either be safely ignored by an HTTP/1.0 recipient
2184    or only be sent when communicating with a party advertising
2185    conformance with HTTP/1.1.
2186
2187
2188Appendix A., paragraph 7:
2189OLD:
2190
2191 A.1.1.  Multi-homed Web Servers
2192
2193NEW:
2194
2195 A.1.1.  Multihomed Web Servers
2196
2197
2198Section 19.7.1, paragraph 8:
2199OLD:
2200
2201    HTTP's approach to error handling has been explained.  (Section 2.5)
2202
2203NEW:
2204
2205    HTTP's approach to error handling has been explained (Section 2.5).
2206
2207
2208Section 19.7.1, paragraph 9:
2209OLD:
2210
2211    The HTTP-version ABNF production has been clarified to be case-
2212    sensitive.  Additionally, version numbers has been restricted to
2213    single digits, due to the fact that implementations are known to
2214    handle multi-digit version numbers incorrectly.  (Section 2.6)
2215
2216NEW:
2217
2218    The HTTP-version ABNF production has been clarified to be case
2219    sensitive.  Additionally, version numbers have been restricted to
2220    single digits, due to the fact that implementations are known to
2221    handle multi-digit version numbers incorrectly (Section 2.6).
2222
2223
2224Section 19.7.1, paragraph 10:
2225OLD:
2226
2227    Userinfo (i.e., username and password) are now disallowed in HTTP and
2228    HTTPS URIs, because of security issues related to their transmission
2229    on the wire.  (Section 2.7.1)
2230
2231NEW:
2232
2233    Userinfo (i.e., username and password) are now disallowed in HTTP and
2234    HTTPS URIs, because of security issues related to their transmission
2235    on the wire (Section 2.7.1).
2236
2237
2238Section 19.7.1, paragraph 11:
2239OLD:
2240
2241    The HTTPS URI scheme is now defined by this specification;
2242    previously, it was done in Section 2.4 of [RFC2818].  Furthermore, it
2243    implies end-to-end security.  (Section 2.7.2)
2244
2245NEW:
2246
2247    The HTTPS URI scheme is now defined by this specification;
2248    previously, it was defined in Section 2.4 of [RFC2818].  Furthermore,
2249    it implies end-to-end security (Section 2.7.2).
2250
2251
2252Section 19.7.1, paragraph 12:
2253OLD:
2254
2255    HTTP messages can be (and often are) buffered by implementations;
2256    despite it sometimes being available as a stream, HTTP is
2257    fundamentally a message-oriented protocol.  Minimum supported sizes
2258    for various protocol elements have been suggested, to improve
2259    interoperability.  (Section 3)
2260
2261NEW:
2262
2263    HTTP messages can be (and often are) buffered by implementations;
2264    despite it sometimes being available as a stream, HTTP is
2265    fundamentally a message-oriented protocol.  Minimum supported sizes
2266    for various protocol elements have been suggested, to improve
2267    interoperability (Section 3).
2268
2269
2270Section 19.7.1, paragraph 13:
2271OLD:
2272
2273    Invalid whitespace around field-names is now required to be rejected,
2274    because accepting it represents a security vulnerability.  The ABNF
2275    productions defining header fields now only list the field value.
2276    (Section 3.2)
2277
2278NEW:
2279
2280    Invalid whitespace around field-names is now required to be rejected,
2281    because accepting it represents a security vulnerability.  The ABNF
2282    productions defining header fields now only list the field value
2283    (Section 3.2).
2284
2285
2286Section 19.7.1, paragraph 14:
2287OLD:
2288
2289    Rules about implicit linear whitespace between certain grammar
2290    productions have been removed; now whitespace is only allowed where
2291    specifically defined in the ABNF.  (Section 3.2.3)
2292
2293NEW:
2294
2295    Rules about implicit linear whitespace between certain grammar
2296    productions have been removed; now whitespace is only allowed where
2297    specifically defined in the ABNF (Section 3.2.3).
2298
2299
2300Section 19.7.1, paragraph 15:
2301OLD:
2302
2303    Header fields that span multiple lines ("line folding") are
2304    deprecated.  (Section 3.2.4)
2305    The NUL octet is no longer allowed in comment and quoted-string text,
2306    and handling of backslash-escaping in them has been clarified.  The
2307    quoted-pair rule no longer allows escaping control characters other
2308    than HTAB.  Non-ASCII content in header fields and the reason phrase
2309    has been obsoleted and made opaque (the TEXT rule was removed).
2310    (Section 3.2.6)
2311
2312NEW:
2313
2314    Header fields that span multiple lines ("line folding") are
2315    deprecated (Section 3.2.4).
2316 
2317    The NUL octet is no longer allowed in comment and quoted-string text,
2318    and handling of backslash-escaping in them has been clarified.  The
2319    quoted-pair rule no longer allows escaping control characters other
2320    than HTAB.  Non-US-ASCII content in header fields and the reason
2321    phrase has been obsoleted and made opaque (the TEXT rule was removed)
2322    (Section 3.2.6).
2323
2324
2325Section 19.7.1, paragraph 16:
2326OLD:
2327
2328    Bogus "Content-Length" header fields are now required to be handled
2329    as errors by recipients.  (Section 3.3.2)
2330
2331NEW:
2332
2333    Bogus "Content-Length" header fields are now required to be handled
2334    as errors by recipients (Section 3.3.2).
2335
2336
2337Section 19.7.1, paragraph 17:
2338OLD:
2339
2340    The algorithm for determining the message body length has been
2341    clarified to indicate all of the special cases (e.g., driven by
2342    methods or status codes) that affect it, and that new protocol
2343    elements cannot define such special cases.  CONNECT is a new, special
2344    case in determining message body length. "multipart/byteranges" is no
2345    longer a way of determining message body length detection.
2346    (Section 3.3.3)
2347
2348NEW:
2349
2350    The algorithm for determining the message body length has been
2351    clarified to indicate all of the special cases (e.g., driven by
2352    methods or status codes) that affect it, and that new protocol
2353    elements cannot define such special cases.  CONNECT is a new, special
2354    case in determining message body length. "multipart/byteranges" is no
2355    longer a way of determining message body length detection
2356    (Section 3.3.3).
2357
2358
2359Section 19.7.1, paragraph 18:
2360OLD:
2361
2362    The "identity" transfer coding token has been removed.  (Sections 3.3
2363    and 4)
2364
2365NEW:
2366
2367    The "identity" transfer coding token has been removed (Sections 3.3
2368    and 4).
2369
2370
2371Section 19.7.1, paragraph 19:
2372OLD:
2373
2374    Chunk length does not include the count of the octets in the chunk
2375    header and trailer.  Line folding in chunk extensions is disallowed.
2376    (Section 4.1)
2377
2378NEW:
2379
2380    Chunk length does not include the count of the octets in the chunk
2381    header and trailer.  Line folding in chunk extensions is disallowed
2382    (Section 4.1).
2383
2384
2385Section 19.7.1, paragraph 20:
2386OLD:
2387
2388    The meaning of the "deflate" content coding has been clarified.
2389    (Section 4.2.2)
2390
2391NEW:
2392
2393    The meaning of the "deflate" content coding has been clarified
2394    (Section 4.2.2).
2395
2396
2397Section 19.7.1, paragraph 21:
2398OLD:
2399
2400    The segment + query components of RFC 3986 have been used to define
2401    the request-target, instead of abs_path from RFC 1808.  The asterisk-
2402    form of the request-target is only allowed with the OPTIONS method.
2403    (Section 5.3)
2404
2405NEW:
2406
2407    The segment + query components of RFC 3986 have been used to define
2408    the request-target, instead of abs_path from RFC 1808.  The asterisk-
2409    form of the request-target is only allowed with the OPTIONS method
2410    (Section 5.3).
2411
2412
2413Section 19.7.1, paragraph 22:
2414OLD:
2415
2416    The term "Effective Request URI" has been introduced.  (Section 5.5)
2417
2418NEW:
2419
2420    The term "Effective Request URI" has been introduced (Section 5.5).
2421
2422
2423Section 19.7.1, paragraph 23:
2424OLD:
2425
2426    Gateways do not need to generate Via header fields anymore.
2427    (Section 5.7.1)
2428
2429NEW:
2430
2431    Gateways do not need to generate Via header fields anymore
2432    (Section 5.7.1).
2433
2434
2435Section 19.7.1, paragraph 24:
2436OLD:
2437
2438    Exactly when "close" connection options have to be sent has been
2439    clarified.  Also, "hop-by-hop" header fields are required to appear
2440    in the Connection header field; just because they're defined as hop-
2441    by-hop in this specification doesn't exempt them.  (Section 6.1)
2442
2443NEW:
2444
2445    Exactly when "close" connection options have to be sent has been
2446    clarified.  Also, "hop-by-hop" header fields are required to appear
2447    in the Connection header field; just because they're defined as hop-
2448    by-hop in this specification doesn't exempt them (Section 6.1).
2449
2450
2451Section 19.7.1, paragraph 25:
2452OLD:
2453
2454    The limit of two connections per server has been removed.  An
2455    idempotent sequence of requests is no longer required to be retried.
2456    The requirement to retry requests under certain circumstances when
2457    the server prematurely closes the connection has been removed.  Also,
2458    some extraneous requirements about when servers are allowed to close
2459    connections prematurely have been removed.  (Section 6.3)
2460
2461NEW:
2462
2463    The limit of two connections per server has been removed.  An
2464    idempotent sequence of requests is no longer required to be retried.
2465    The requirement to retry requests under certain circumstances when
2466    the server prematurely closes the connection has been removed.  Also,
2467    some extraneous requirements about when servers are allowed to close
2468    connections prematurely have been removed (Section 6.3).
2469
2470
2471Section 19.7.1, paragraph 26:
2472OLD:
2473
2474    The semantics of the Upgrade header field is now defined in responses
2475    other than 101 (this was incorporated from [RFC2817]).  Furthermore,
2476    the ordering in the field value is now significant.  (Section 6.7)
2477
2478NEW:
2479
2480    The semantics of the Upgrade header field is now defined in responses
2481    other than 101 (this was incorporated from [RFC2817]).  Furthermore,
2482    the ordering in the field value is now significant (Section 6.7).
2483
2484
2485Section 19.7.1, paragraph 27:
2486OLD:
2487
2488    Empty list elements in list productions (e.g., a list header field
2489    containing ", ,") have been deprecated.  (Section 7)
2490
2491NEW:
2492
2493    Empty list elements in list productions (e.g., a list header field
2494    containing ", ,") have been deprecated (Section 7).
2495
2496
2497Section 19.7.1, paragraph 28:
2498OLD:
2499
2500    Registration of Transfer Codings now requires IETF Review
2501    (Section 8.4)
2502
2503NEW:
2504
2505    Registration of Transfer Codings now requires IETF Review
2506    (Section 8.4).
2507
2508
2509Section 19.7.1, paragraph 29:
2510OLD:
2511
2512    This specification now defines the Upgrade Token Registry, previously
2513    defined in Section 7.2 of [RFC2817].  (Section 8.6)
2514
2515NEW:
2516
2517    This specification now defines the "HTTP Upgrade Tokens" registry,
2518    previously defined in Section 7.2 of [RFC2817] (Section 8.6).
2519
2520
2521Section 19.7.1, paragraph 30:
2522OLD:
2523
2524    The expectation to support HTTP/0.9 requests has been removed.
2525    (Appendix A)
2526
2527NEW:
2528
2529    The expectation to support HTTP/0.9 requests has been removed
2530    (Appendix A).
2531
2532
2533Section 19.7.1, paragraph 31:
2534OLD:
2535
2536    Issues with the Keep-Alive and Proxy-Connection header fields in
2537    requests are pointed out, with use of the latter being discouraged
2538    altogether.  (Appendix A.1.2)
2539
2540NEW:
2541
2542    Issues with the Keep-Alive and Proxy-Connection header fields in
2543    requests are pointed out, with use of the latter being discouraged
2544    altogether (Appendix A.1.2).
2545
2546
2547Appendix B., paragraph 7:
2548OLD:
2549
2550    URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
2551    Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
2552    Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
2553     ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
2554     comment ] ) ] )
2555
2556NEW:
2557
2558    URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
2559    Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
2560 
2561    Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
2562     ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
2563     comment ] ) ] )
2564
2565
2566Appendix B., paragraph 15:
2567OLD:
2568
2569    partial-URI = relative-part [ "?" query ]
2570    path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
2571    port = <port, defined in [RFC3986], Section 3.2.3>
2572    protocol = protocol-name [ "/" protocol-version ]
2573    protocol-name = token
2574    protocol-version = token
2575    pseudonym = token
2576 
2577    qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
2578     / %x5D-7E ; ']'-'~'
2579     / obs-text
2580    query = <query, defined in [RFC3986], Section 3.4>
2581    quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
2582    quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
2583
2584NEW:
2585
2586    partial-URI = relative-part [ "?" query ]
2587    path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
2588    port = <port, defined in [RFC3986], Section 3.2.3>
2589    protocol = protocol-name [ "/" protocol-version ]
2590    protocol-name = token
2591    protocol-version = token
2592    pseudonym = token
2593    qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
2594     / %x5D-7E ; ']'-'~'
2595     / obs-text
2596    query = <query, defined in [RFC3986], Section 3.4>
2597    quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
2598    quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
2599
2600
2601Appendix B., paragraph 24:
2602OLD:
2603
2604    D
2605       deflate (Coding Format)  38
2606       Delimiters  26
2607       downstream  9
2608
2609NEW:
2610
2611    D
2612       deflate (Coding Format)  38
2613       Delimiters  26
2614       downstream  10
2615
2616
2617Appendix B., paragraph 26:
2618OLD:
2619
2620    G
2621       gateway  10
2622       Grammar
2623          absolute-form  41-42
2624          absolute-path  16
2625          absolute-URI  16
2626          ALPHA  6
2627          asterisk-form  41-42
2628          authority  16
2629          authority-form  41-42
2630          BWS  24
2631          chunk  35
2632          chunk-data  35
2633          chunk-ext  35-36
2634          chunk-ext-name  36
2635          chunk-ext-val  36
2636          chunk-size  35
2637          chunked-body  35-36
2638          comment  27
2639          Connection  51
2640          connection-option  51
2641          Content-Length  30
2642          CR  6
2643          CRLF  6
2644          ctext  27
2645          CTL  6
2646          DIGIT  6
2647          DQUOTE  6
2648          field-content  22
2649          field-name  22, 39
2650          field-value  22
2651          field-vchar  22
2652          fragment  16
2653          header-field  22, 36
2654          HEXDIG  6
2655          Host  43
2656          HTAB  6
2657          HTTP-message  19
2658          HTTP-name  13
2659          http-URI  16
2660          HTTP-version  13
2661          https-URI  18
2662          last-chunk  35
2663          LF  6
2664          message-body  27
2665          method  21
2666          obs-fold  22
2667          obs-text  27
2668          OCTET  6
2669          origin-form  41
2670          OWS  24
2671          partial-URI  16
2672          port  16
2673          protocol-name  47
2674          protocol-version  47
2675          pseudonym  47
2676          qdtext  27
2677          query  16
2678          quoted-pair  27
2679          quoted-string  27
2680          rank  38
2681          reason-phrase  22
2682          received-by  47
2683          received-protocol  47
2684          request-line  21
2685          request-target  41
2686          RWS  24
2687          scheme  16
2688          segment  16
2689          SP  6
2690          start-line  20
2691          status-code  22
2692          status-line  22
2693          t-codings  38
2694          t-ranking  38
2695          tchar  27
2696          TE  38
2697          token  27
2698          Trailer  39
2699          trailer-part  35-36
2700          transfer-coding  35
2701          Transfer-Encoding  28
2702          transfer-extension  35
2703          transfer-parameter  35
2704          Upgrade  56
2705          uri-host  16
2706          URI-reference  16
2707          VCHAR  6
2708          Via  47
2709       gzip (Coding Format)  38
2710
2711NEW:
2712
2713    G
2714       gateway  10
2715       Grammar
2716          absolute-form  41-42
2717          absolute-path  16
2718          absolute-URI  16
2719          ALPHA  6
2720          asterisk-form  41-42
2721          authority  16
2722          authority-form  41-42
2723          BWS  24
2724          chunk  35
2725          chunk-data  35
2726          chunk-ext  35-36
2727          chunk-ext-name  36
2728          chunk-ext-val  36
2729          chunk-size  35
2730          chunked-body  35-36
2731          comment  27
2732          Connection  51
2733          connection-option  51
2734          Content-Length  30
2735          CR  6
2736          CRLF  6
2737          ctext  27
2738          CTL  6
2739          DIGIT  6
2740          DQUOTE  6
2741          field-content  22
2742          field-name  22, 39
2743          field-value  22
2744          field-vchar  22
2745          fragment  16
2746          header-field  22, 36
2747          HEXDIG  6
2748          Host  43
2749          HTAB  6
2750          HTTP-message  19
2751          HTTP-name  14
2752          http-URI  16
2753          HTTP-version  14
2754          https-URI  18
2755          last-chunk  35
2756          LF  6
2757          message-body  27
2758          method  21
2759          obs-fold  22
2760          obs-text  27
2761          OCTET  6
2762          origin-form  41
2763          OWS  24
2764          partial-URI  16
2765          port  16
2766          protocol-name  47
2767          protocol-version  47
2768          pseudonym  47
2769          qdtext  27
2770          query  16
2771          quoted-pair  27
2772          quoted-string  27
2773          rank  38
2774          reason-phrase  22
2775          received-by  47
2776          received-protocol  47
2777          request-line  21
2778          request-target  41
2779          RWS  24
2780          scheme  16
2781          segment  16
2782          SP  6
2783          start-line  20
2784          status-code  22
2785          status-line  22
2786          t-codings  38
2787          t-ranking  38
2788          tchar  27
2789          TE  38
2790          token  27
2791          Trailer  39
2792          trailer-part  35-36
2793          transfer-coding  35
2794          Transfer-Encoding  28
2795          transfer-extension  35
2796          transfer-parameter  35
2797          Upgrade  56
2798          uri-host  16
2799          URI-reference  16
2800          VCHAR  6
2801          Via  47
2802       gzip (Coding Format)  38
2803
2804
2805Appendix B., paragraph 28:
2806OLD:
2807
2808    I
2809       inbound  9
2810       interception proxy  11
2811       intermediary  9
2812
2813NEW:
2814
2815    I
2816       inbound  10
2817       interception proxy  11
2818       intermediary  9
2819
2820
2821Appendix B., paragraph 31:
2822OLD:
2823
2824    O
2825       origin server  7
2826       origin-form (of request-target)  41
2827       outbound  9
2828
2829NEW:
2830
2831    O
2832       origin server  7
2833       origin-form (of request-target)  41
2834       outbound  10
2835
2836
2837Appendix B., paragraph 36:
2838OLD:
2839
2840    U
2841       Upgrade header field  56
2842       upstream  9
2843       URI scheme
2844          http  16
2845          https  18
2846       user agent  7
2847
2848NEW:
2849
2850    U
2851       Upgrade header field  56
2852       upstream  10
2853       URI scheme
2854          http  16
2855          https  18
2856       user agent  7
2857
2858
2859Section 345, paragraph 1:
2860OLD:
2861
2862    EMail: fielding@gbiv.com
2863    URI:   http://roy.gbiv.com/
2864 
2865    Julian F. Reschke (editor)
2866    greenbytes GmbH
2867    Hafenweg 16
2868    Muenster, NW  48155
2869    Germany
2870
2871NEW:
2872
2873    EMail: fielding@gbiv.com
2874    URI:   http://roy.gbiv.com/
2875    Julian F. Reschke (editor)
2876    greenbytes GmbH
2877    Hafenweg 16
2878    Muenster, NW  48155
2879    Germany
2880
Note: See TracBrowser for help on using the repository browser.