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

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

"time-out" -> "timeout"/"time out" (#553)

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