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

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

add subproject for auth48 checks (#553)

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