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

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

whitespace in boilerplate (#553)

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