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

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

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