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

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

"ad-hoc" -> "ad hoc" (#553)

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