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

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

punctuation (#553)

File size: 100.3 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 400, paragraph 2:
809OLD:
810
811    Various ad-hoc limitations on request-line length are found in
812    practice.  It is RECOMMENDED that all HTTP senders and recipients
813    support, at a minimum, request-line lengths of 8000 octets.
814
815NEW:
816
817    Various ad hoc limitations on request-line length are found in
818    practice.  It is RECOMMENDED that all HTTP senders and recipients
819    support, at a minimum, request-line lengths of 8000 octets.
820
821
822Section 3.1.2., paragraph 1:
823OLD:
824
825    The first line of a response message is the status-line, consisting
826    of the protocol version, a space (SP), the status code, another
827    space, a possibly-empty textual phrase describing the status code,
828    and ending with CRLF.
829
830NEW:
831
832    The first line of a response message is the status-line, consisting
833    of the protocol version, a space (SP), the status code, another space
834    (SP), a possibly empty textual phrase describing the status code,
835    and, finally, CRLF.
836
837
838Section 3.2.1., paragraph 4:
839OLD:
840
841    All defined header fields ought to be registered with IANA in the
842    Message Header Field Registry, as described in Section 8.3 of
843    [RFC7231].
844
845NEW:
846
847    All defined header fields ought to be registered with IANA in the
848    "Message Headers" field registry, as described in Section 8.3 of
849    [RFC7231].
850
851
852Section 3.2.2., paragraph 4:
853OLD:
854
855       Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
856       appears multiple times in a response message and does not use the
857       list syntax, violating the above requirements on multiple header
858       fields with the same name.  Since it cannot be combined into a
859       single field-value, recipients ought to handle "Set-Cookie" as a
860       special case while processing header fields.  (See Appendix A.2.3
861       of [Kri2001] for details.)
862
863NEW:
864
865       Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
866       appears multiple times in a response message and does not use the
867       list syntax, violating the above requirements on multiple header
868       fields with the same name.  Since it cannot be combined into a
869       single field-value, recipients ought to handle Set-Cookie as a
870       special case while processing header fields.  (See Appendix A.2.3
871       of [Kri2001] for details.)
872
873
874Section 3.2.3., paragraph 2:
875OLD:
876
877    The OWS rule is used where zero or more linear whitespace octets
878    might appear.  For protocol elements where optional whitespace is
879    preferred to improve readability, a sender SHOULD generate the
880    optional whitespace as a single SP; otherwise, a sender SHOULD NOT
881    generate optional whitespace except as needed to white-out invalid or
882    unwanted protocol elements during in-place message filtering.
883
884NEW:
885
886    The OWS rule is used where zero or more linear whitespace octets
887    might appear.  For protocol elements where optional whitespace is
888    preferred to improve readability, a sender SHOULD generate the
889    optional whitespace as a single SP; otherwise, a sender SHOULD NOT
890    generate optional whitespace except as needed to white out invalid or
891    unwanted protocol elements during in-place message filtering.
892
893
894Section 3.2.4., paragraph 1:
895OLD:
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 which
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
909NEW:
910
911    Messages are parsed using a generic algorithm, independent of the
912    individual header field names.  The contents within a given field
913    value are not parsed until a later stage of message interpretation
914    (usually after the message's entire header section has been
915    processed).  Consequently, this specification does not use ABNF rules
916    to define each "field-name: field-value" pair, as was done in
917    previous editions.  Instead, this specification uses ABNF rules that
918    are named according to each registered field name, wherein the rule
919    defines the valid grammar for that field's corresponding field values
920    (i.e., after the field-value has been extracted from the header
921    section by a generic field parser).
922
923
924Section 3.2.4., paragraph 8:
925OLD:
926
927    Historically, HTTP has allowed field content with text in the ISO-
928    8859-1 [ISO-8859-1] charset, supporting other charsets only through
929    use of [RFC2047] encoding.  In practice, most HTTP header field
930    values use only a subset of the US-ASCII charset [USASCII].  Newly
931    defined header fields SHOULD limit their field values to US-ASCII
932    octets.  A recipient SHOULD treat other octets in field content (obs-
933    text) as opaque data.
934
935NEW:
936
937    Historically, HTTP has allowed field content with text in the
938    ISO-8859-1 [ISO-8859-1] charset, supporting other charsets only
939    through use of [RFC2047] encoding.  In practice, most HTTP header
940    field values use only a subset of the US-ASCII charset [USASCII].
941    Newly defined header fields SHOULD limit their field values to
942    US-ASCII octets.  A recipient SHOULD treat other octets in field
943    content (obs-text) as opaque data.
944
945
946Section 3.2.5., paragraph 1:
947OLD:
948
949    HTTP does not place a pre-defined limit on the length of each header
950    field or on the length of the header section as a whole, as described
951    in Section 2.5.  Various ad-hoc limitations on individual header
952    field length are found in practice, often depending on the specific
953    field semantics.
954
955NEW:
956
957    HTTP does not place a predefined limit on the length of each header
958    field or on the length of the header section as a whole, as described
959    in Section 2.5.  Various ad hoc limitations on individual header
960    field length are found in practice, often depending on the specific
961    field semantics.
962
963
964Section 7., paragraph 1:
965OLD:
966
967    Since there is no way to distinguish a successfully completed, close-
968    delimited message from a partially-received message interrupted by
969    network failure, a server SHOULD generate encoding or length-
970    delimited messages whenever possible.  The close-delimiting feature
971    exists primarily for backwards compatibility with HTTP/1.0.
972
973NEW:
974
975    Since there is no way to distinguish a successfully completed, close-
976    delimited message from a partially received message interrupted by
977    network failure, a server SHOULD generate encoding or length-
978    delimited messages whenever possible.  The close-delimiting feature
979    exists primarily for backwards compatibility with HTTP/1.0.
980
981
982Section 3.4., paragraph 1:
983OLD:
984
985    A server that receives an incomplete request message, usually due to
986    a canceled request or a triggered time-out exception, MAY send an
987    error response prior to closing the connection.
988
989NEW:
990
991    A server that receives an incomplete request message, usually due to
992    a canceled request or a triggered timeout exception, MAY send an
993    error response prior to closing the connection.
994
995
996Section 4., paragraph 5:
997OLD:
998
999    All transfer-coding names are case-insensitive and ought to be
1000    registered within the HTTP Transfer Coding registry, as defined in
1001    Section 8.4.  They are used in the TE (Section 4.3) and Transfer-
1002    Encoding (Section 3.3.1) header fields.
1003
1004NEW:
1005
1006    All transfer-coding names are case insensitive and ought to be
1007    registered within the "HTTP Transfer Coding" registry, as defined in
1008    Section 8.4.  They are used in the TE (Section 4.3) and Transfer-
1009    Encoding (Section 3.3.1) header fields.
1010
1011
1012Section 4.2.3., paragraph 1:
1013OLD:
1014
1015    The "gzip" coding is an LZ77 coding with a 32 bit CRC that is
1016    commonly produced by the gzip file compression program [RFC1952].  A
1017    recipient SHOULD consider "x-gzip" to be equivalent to "gzip".
1018
1019NEW:
1020
1021    The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy
1022    Check (CRC) that is commonly produced by the gzip file compression
1023    program [RFC1952].  A recipient SHOULD consider "x-gzip" to be
1024    equivalent to "gzip".
1025
1026
1027Section 5.7.2., paragraph 6:
1028OLD:
1029
1030    A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of
1031    a message that contains a no-transform cache-control directive
1032    (Section 5.2 of [RFC7234]).
1033
1034NEW:
1035
1036    A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of
1037    a message that contains a no-transform Cache-Control directive
1038    (Section 5.2 of [RFC7234]).
1039
1040
1041Section 200, paragraph 0:
1042OLD:
1043
1044    A proxy MAY transform the payload of a message that does not contain
1045    a no-transform cache-control directive.  A proxy that transforms a
1046    payload MUST add a Warning header field with the warn-code of 214
1047    ("Transformation Applied") if one is not already in the message (see
1048    Section 5.5 of [RFC7234]).  A proxy that transforms the payload of a
1049    200 (OK) response can further inform downstream recipients that a
1050    transformation has been applied by changing the response status code
1051    to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).
1052
1053NEW:
1054
1055    A proxy MAY transform the payload of a message that does not contain
1056    a no-transform Cache-Control directive.  A proxy that transforms a
1057    payload MUST add a Warning header field with the warn-code of 214
1058    ("Transformation Applied") if one is not already in the message (see
1059    Section 5.5 of [RFC7234]).  A proxy that transforms the payload of a
1060    200 (OK) response can further inform downstream recipients that a
1061    transformation has been applied by changing the response status code
1062    to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).
1063
1064
1065Section 6., paragraph 1:
1066OLD:
1067
1068    HTTP messaging is independent of the underlying transport or session-
1069    layer connection protocol(s).  HTTP only presumes a reliable
1070    transport with in-order delivery of requests and the corresponding
1071    in-order delivery of responses.  The mapping of HTTP request and
1072    response structures onto the data units of an underlying transport
1073    protocol is outside the scope of this specification.
1074
1075NEW:
1076
1077    HTTP messaging is independent of the underlying transport- or
1078    session-layer connection protocol(s).  HTTP only presumes a reliable
1079    transport with in-order delivery of requests and the corresponding
1080    in-order delivery of responses.  The mapping of HTTP request and
1081    response structures onto the data units of an underlying transport
1082    protocol is outside the scope of this specification.
1083
1084
1085Section 6., paragraph 3:
1086OLD:
1087
1088    HTTP implementations are expected to engage in connection management,
1089    which includes maintaining the state of current connections,
1090    establishing a new connection or reusing an existing connection,
1091    processing messages received on a connection, detecting connection
1092    failures, and closing each connection.  Most clients maintain
1093    multiple connections in parallel, including more than one connection
1094    per server endpoint.  Most servers are designed to maintain thousands
1095    of concurrent connections, while controlling request queues to enable
1096    fair use and detect denial of service attacks.
1097
1098NEW:
1099
1100    HTTP implementations are expected to engage in connection management,
1101    which includes maintaining the state of current connections,
1102    establishing a new connection or reusing an existing connection,
1103    processing messages received on a connection, detecting connection
1104    failures, and closing each connection.  Most clients maintain
1105    multiple connections in parallel, including more than one connection
1106    per server endpoint.  Most servers are designed to maintain thousands
1107    of concurrent connections, while controlling request queues to enable
1108    fair use and detect denial-of-service attacks.
1109
1110
1111Section 6.1., paragraph 6:
1112OLD:
1113
1114    Connection options are case-insensitive.
1115
1116NEW:
1117
1118    Connection options are case insensitive.
1119
1120
1121Section 6.2., paragraph 1:
1122OLD:
1123
1124    It is beyond the scope of this specification to describe how
1125    connections are established via various transport or session-layer
1126    protocols.  Each connection applies to only one transport link.
1127
1128NEW:
1129
1130    It is beyond the scope of this specification to describe how
1131    connections are established via various transport- or session-layer
1132    protocols.  Each connection applies to only one transport link.
1133
1134
1135Section 6.3., paragraph 1:
1136OLD:
1137
1138    HTTP/1.1 defaults to the use of "persistent connections", allowing
1139    multiple requests and responses to be carried over a single
1140    connection.  The "close" connection-option is used to signal that a
1141    connection will not persist after the current request/response.  HTTP
1142    implementations SHOULD support persistent connections.
1143
1144NEW:
1145
1146    HTTP/1.1 defaults to the use of "persistent connections", allowing
1147    multiple requests and responses to be carried over a single
1148    connection.  The "close" connection option is used to signal that a
1149    connection will not persist after the current request/response.  HTTP
1150    implementations SHOULD support persistent connections.
1151
1152
1153Section 6.3., paragraph 3:
1154OLD:
1155
1156    o  If the close connection option is present, the connection will not
1157       persist after the current response; else,
1158
1159NEW:
1160
1161    o  If the "close" connection option is present, the connection will
1162       not persist after the current response; else,
1163
1164
1165Section 6.3., paragraph 7:
1166OLD:
1167
1168    A client MAY send additional requests on a persistent connection
1169    until it sends or receives a close connection option or receives an
1170    HTTP/1.0 response without a "keep-alive" connection option.
1171
1172NEW:
1173
1174    A client MAY send additional requests on a persistent connection
1175    until it sends or receives a "close" connection option or receives an
1176    HTTP/1.0 response without a "keep-alive" connection option.
1177
1178
1179Section 6.3., paragraph 10:
1180OLD:
1181
1182    See Appendix A.1.2 for more information on backward compatibility
1183    with HTTP/1.0 clients.
1184
1185NEW:
1186
1187    See Appendix A.1.2 for more information on backwards compatibility
1188    with HTTP/1.0 clients.
1189
1190
1191Section 6.3.2., paragraph 1:
1192OLD:
1193
1194    A client that supports persistent connections MAY "pipeline" its
1195    requests (i.e., send multiple requests without waiting for each
1196    response).  A server MAY process a sequence of pipelined requests in
1197    parallel if they all have safe methods (Section 4.2.1 of [RFC7231]),
1198    but MUST send the corresponding responses in the same order that the
1199    requests were received.
1200
1201NEW:
1202
1203    A client that supports persistent connections MAY "pipeline" its
1204    requests (i.e., send multiple requests without waiting for each
1205    response).  A server MAY process a sequence of pipelined requests in
1206    parallel if they all have safe methods (Section 4.2.1 of [RFC7231]),
1207    but it MUST send the corresponding responses in the same order that
1208    the requests were received.
1209
1210
1211Section 6.4., paragraph 4:
1212OLD:
1213
1214    Note that a server might reject traffic that it deems abusive or
1215    characteristic of a denial of service attack, such as an excessive
1216    number of open connections from a single client.
1217
1218NEW:
1219
1220    Note that a server might reject traffic that it deems abusive or
1221    characteristic of a denial-of-service attack, such as an excessive
1222    number of open connections from a single client.
1223
1224
1225Section 6.4., paragraph 5:
1226OLD:
1227
1228 6.5.  Failures and Time-outs
1229
1230NEW:
1231
1232 6.5.  Failures and Timeouts
1233
1234
1235Section 6.4., paragraph 6:
1236OLD:
1237
1238    Servers will usually have some time-out value beyond which they will
1239    no longer maintain an inactive connection.  Proxy servers might make
1240    this a higher value since it is likely that the client will be making
1241    more connections through the same proxy server.  The use of
1242    persistent connections places no requirements on the length (or
1243    existence) of this time-out for either the client or the server.
1244
1245NEW:
1246
1247    Servers will usually have some timeout value beyond which they will
1248    no longer maintain an inactive connection.  Proxy servers might make
1249    this a higher value since it is likely that the client will be making
1250    more connections through the same proxy server.  The use of
1251    persistent connections places no requirements on the length (or
1252    existence) of this timeout for either the client or the server.
1253
1254
1255Section 6.4., paragraph 7:
1256OLD:
1257
1258    A client or server that wishes to time-out SHOULD issue a graceful
1259    close on the connection.  Implementations SHOULD constantly monitor
1260    open connections for a received closure signal and respond to it as
1261    appropriate, since prompt closure of both sides of a connection
1262    enables allocated system resources to be reclaimed.
1263
1264NEW:
1265
1266    A client or server that wishes to time out SHOULD issue a graceful
1267    close on the connection.  Implementations SHOULD constantly monitor
1268    open connections for a received closure signal and respond to it as
1269    appropriate, since prompt closure of both sides of a connection
1270    enables allocated system resources to be reclaimed.
1271
1272
1273Section 6.4., paragraph 9:
1274OLD:
1275
1276    A server SHOULD sustain persistent connections, when possible, and
1277    allow the underlying transport's flow control mechanisms to resolve
1278    temporary overloads, rather than terminate connections with the
1279    expectation that clients will retry.  The latter technique can
1280    exacerbate network congestion.
1281
1282NEW:
1283
1284    A server SHOULD sustain persistent connections, when possible, and
1285    allow the underlying transport's flow-control mechanisms to resolve
1286    temporary overloads, rather than terminate connections with the
1287    expectation that clients will retry.  The latter technique can
1288    exacerbate network congestion.
1289
1290
1291Section 6.4., paragraph 11:
1292OLD:
1293
1294 6.6.  Tear-down
1295
1296NEW:
1297
1298 6.6.  Teardown
1299
1300
1301Section 6.4., paragraph 13:
1302OLD:
1303
1304    A client that sends a close connection option MUST NOT send further
1305    requests on that connection (after the one containing close) and MUST
1306    close the connection after reading the final response message
1307    corresponding to this request.
1308
1309NEW:
1310
1311    A client that sends a "close" connection option MUST NOT send further
1312    requests on that connection (after the one containing close) and MUST
1313    close the connection after reading the final response message
1314    corresponding to this request.
1315
1316
1317Section 6.4., paragraph 14:
1318OLD:
1319
1320    A server that receives a close connection option MUST initiate a
1321    close of the connection (see below) after it sends the final response
1322    to the request that contained close.  The server SHOULD send a close
1323    connection option in its final response on that connection.  The
1324    server MUST NOT process any further requests received on that
1325    connection.
1326
1327NEW:
1328
1329    A server that receives a "close" connection option MUST initiate a
1330    close of the connection (see below) after it sends the final response
1331    to the request that contained close.  The server SHOULD send a close
1332    connection option in its final response on that connection.  The
1333    server MUST NOT process any further requests received on that
1334    connection.
1335
1336
1337Section 6.4., paragraph 15:
1338OLD:
1339
1340    A server that sends a close connection option MUST initiate a close
1341    of the connection (see below) after it sends the response containing
1342    close.  The server MUST NOT process any further requests received on
1343    that connection.
1344
1345NEW:
1346
1347    A server that sends a "close" connection option MUST initiate a close
1348    of the connection (see below) after it sends the response containing
1349    close.  The server MUST NOT process any further requests received on
1350    that connection.
1351
1352
1353Section 6.4., paragraph 16:
1354OLD:
1355
1356    A client that receives a close connection option MUST cease sending
1357    requests on that connection and close the connection after reading
1358    the response message containing the close; if additional pipelined
1359    requests had been sent on the connection, the client SHOULD NOT
1360    assume that they will be processed by the server.
1361
1362NEW:
1363
1364    A client that receives a "close" connection option MUST cease sending
1365    requests on that connection and close the connection after reading
1366    the response message containing the close; if additional pipelined
1367    requests had been sent on the connection, the client SHOULD NOT
1368    assume that they will be processed by the server.
1369
1370
1371Section 6.4., paragraph 17:
1372OLD:
1373
1374    If a server performs an immediate close of a TCP connection, there is
1375    a significant risk that the client will not be able to read the last
1376    HTTP response.  If the server receives additional data from the
1377    client on a fully-closed connection, such as another request that was
1378    sent by the client before receiving the server's response, the
1379    server's TCP stack will send a reset packet to the client;
1380    unfortunately, the reset packet might erase the client's
1381    unacknowledged input buffers before they can be read and interpreted
1382    by the client's HTTP parser.
1383
1384NEW:
1385
1386    If a server performs an immediate close of a TCP connection, there is
1387    a significant risk that the client will not be able to read the last
1388    HTTP response.  If the server receives additional data from the
1389    client on a fully closed connection, such as another request that was
1390    sent by the client before receiving the server's response, the
1391    server's TCP stack will send a reset packet to the client;
1392    unfortunately, the reset packet might erase the client's
1393    unacknowledged input buffers before they can be read and interpreted
1394    by the client's HTTP parser.
1395
1396
1397Section 6.7., paragraph 9:
1398OLD:
1399
1400    The capabilities and nature of the application-level communication
1401    after the protocol change is entirely dependent upon the new
1402    protocol(s) chosen.  However, immediately after sending the 101
1403    response, the server is expected to continue responding to the
1404    original request as if it had received its equivalent within the new
1405    protocol (i.e., the server still has an outstanding request to
1406    satisfy after the protocol has been changed, and is expected to do so
1407    without requiring the request to be repeated).
1408
1409NEW:
1410
1411    The capabilities and nature of the application-level communication
1412    after the protocol change is entirely dependent upon the new
1413    protocol(s) chosen.  However, immediately after sending the 101
1414    (Switching Protocols) response, the server is expected to continue
1415    responding to the original request as if it had received its
1416    equivalent within the new protocol (i.e., the server still has an
1417    outstanding request to satisfy after the protocol has been changed,
1418    and is expected to do so without requiring the request to be
1419    repeated).
1420
1421
1422Section 101, paragraph 0:
1423OLD:
1424
1425    For example, if the Upgrade header field is received in a GET request
1426    and the server decides to switch protocols, it first responds with a
1427    101 (Switching Protocols) message in HTTP/1.1 and then immediately
1428    follows that with the new protocol's equivalent of a response to a
1429    GET on the target resource.  This allows a connection to be upgraded
1430    to protocols with the same semantics as HTTP without the latency cost
1431    of an additional round-trip.  A server MUST NOT switch protocols
1432    unless the received message semantics can be honored by the new
1433    protocol; an OPTIONS request can be honored by any protocol.
1434
1435NEW:
1436
1437    For example, if the Upgrade header field is received in a GET request
1438    and the server decides to switch protocols, it first responds with a
1439    101 (Switching Protocols) message in HTTP/1.1 and then immediately
1440    follows that with the new protocol's equivalent of a response to a
1441    GET on the target resource.  This allows a connection to be upgraded
1442    to protocols with the same semantics as HTTP without the latency cost
1443    of an additional round trip.  A server MUST NOT switch protocols
1444    unless the received message semantics can be honored by the new
1445    protocol; an OPTIONS request can be honored by any protocol.
1446
1447
1448Section 101, paragraph 5:
1449OLD:
1450
1451    A client cannot begin using an upgraded protocol on the connection
1452    until it has completely sent the request message (i.e., the client
1453    can't change the protocol it is sending in the middle of a message).
1454    If a server receives both Upgrade and an Expect header field with the
1455    "100-continue" expectation (Section 5.1.1 of [RFC7231]), the server
1456    MUST send a 100 (Continue) response before sending a 101 (Switching
1457    Protocols) response.
1458
1459NEW:
1460
1461    A client cannot begin using an upgraded protocol on the connection
1462    until it has completely sent the request message (i.e., the client
1463    can't change the protocol it is sending in the middle of a message).
1464    If a server receives both an Upgrade and an Expect header field with
1465    the "100-continue" expectation (Section 5.1.1 of [RFC7231]), the
1466    server MUST send a 100 (Continue) response before sending a 101
1467    (Switching Protocols) response.
1468
1469
1470Section 7., paragraph 9:
1471OLD:
1472
1473    For compatibility with legacy list rules, a recipient MUST parse and
1474    ignore a reasonable number of empty list elements: enough to handle
1475    common mistakes by senders that merge values, but not so much that
1476    they could be used as a denial of service mechanism.  In other words,
1477    a recipient MUST accept lists that satisfy the following syntax:
1478
1479NEW:
1480
1481    For compatibility with legacy list rules, a recipient MUST parse and
1482    ignore a reasonable number of empty list elements: enough to handle
1483    common mistakes by senders that merge values, but not so much that
1484    they could be used as a denial-of-service mechanism.  In other words,
1485    a recipient MUST accept lists that satisfy the following syntax:
1486
1487
1488Section 7., paragraph 14:
1489OLD:
1490
1491    Then the following are valid values for example-list (not including
1492    the double quotes, which are present for delimitation only):
1493
1494NEW:
1495
1496    Then, the following are valid values for example-list (not including
1497    the double quotes, which are present for delimitation only):
1498
1499
1500Section 8.1., paragraph 1:
1501OLD:
1502
1503    HTTP header fields are registered within the Message Header Field
1504    Registry maintained at
1505    <http://www.iana.org/assignments/message-headers/>.
1506
1507NEW:
1508
1509    HTTP header fields are registered within the "Message Header" field
1510    registry maintained at
1511    <http://www.iana.org/assignments/message-headers/>.
1512
1513
1514Section 8.1., paragraph 2:
1515OLD:
1516
1517    This document defines the following HTTP header fields, so their
1518    associated registry entries shall be updated according to the
1519    permanent registrations below (see [BCP90]):
1520
1521NEW:
1522
1523    This document defines the following HTTP header fields, so the
1524    "Permanent Message Header Field Names" registry has been updated
1525    accordingly (see [BCP90]).
1526
1527
1528Section 8.1., paragraph 4:
1529OLD:
1530
1531    Furthermore, the header field-name "Close" shall be registered as
1532    "reserved", since using that name as an HTTP header field might
1533    conflict with the "close" connection option of the "Connection"
1534    header field (Section 6.1).
1535
1536NEW:
1537
1538    Furthermore, the header field-name "Close" has been registered as
1539    "reserved", since using that name as an HTTP header field might
1540    conflict with the "close" connection option of the "Connection"
1541    header field (Section 6.1).
1542
1543
1544Section 8.2., paragraph 2:
1545OLD:
1546
1547    This document defines the following URI schemes, so their associated
1548    registry entries shall be updated according to the permanent
1549    registrations below:
1550
1551NEW:
1552
1553    This document defines the following URI schemes, so the "Permanent
1554    URI Schemes" registry has been updated accordingly.
1555
1556
1557Section 8.3., paragraph 2:
1558OLD:
1559
1560    This document serves as the specification for the Internet media
1561    types "message/http" and "application/http".  The following is to be
1562    registered with IANA.
1563
1564NEW:
1565
1566    This document serves as the specification for the Internet media
1567    types "message/http" and "application/http".  The following has been
1568    registered with IANA.
1569
1570
1571Section 8.3.1., paragraph 18:
1572OLD:
1573
1574    Person and email address to contact for further information:  See
1575       Authors Section.
1576
1577NEW:
1578
1579    Person and email address to contact for further information:
1580       See Authors' Addresses  Section.
1581
1582
1583Section 8.3.1., paragraph 21:
1584OLD:
1585
1586    Author:  See Authors Section.
1587
1588NEW:
1589
1590    Author:  See Authors' Addresses Section.
1591
1592
1593Section 8.3.2., paragraph 8:
1594OLD:
1595
1596    Encoding considerations:  HTTP messages enclosed by this type are in
1597       "binary" format; use of an appropriate Content-Transfer-Encoding
1598       is required when transmitted via E-mail.
1599
1600NEW:
1601
1602    Encoding considerations:  HTTP messages enclosed by this type are in
1603       "binary" format; use of an appropriate Content-Transfer-Encoding
1604       is required when transmitted via email.
1605
1606
1607Section 8.3.2., paragraph 19:
1608OLD:
1609
1610    Person and email address to contact for further information:  See
1611       Authors Section.
1612
1613NEW:
1614
1615    Person and email address to contact for further information:
1616       See Authors' Addresses Section.
1617
1618
1619Section 8.3.2., paragraph 22:
1620OLD:
1621
1622    Author:  See Authors Section.
1623
1624NEW:
1625
1626    Author:  See Authors' Addresses Section.
1627
1628
1629Section 8.4., paragraph 1:
1630OLD:
1631
1632    The HTTP Transfer Coding Registry defines the name space for transfer
1633    coding names.  It is maintained at
1634    <http://www.iana.org/assignments/http-parameters>.
1635
1636NEW:
1637
1638    The "HTTP Transfer Coding" registry defines the namespace for
1639    transfer coding names.  It is maintained at
1640    <http://www.iana.org/assignments/http-parameters>.
1641
1642
1643Section 8.4.1., paragraph 5:
1644OLD:
1645
1646    Values to be added to this name space require IETF Review (see
1647    Section 4.1 of [RFC5226]), and MUST conform to the purpose of
1648    transfer coding defined in this specification.
1649
1650NEW:
1651
1652    Values to be added to this namespace require IETF Review (see Section
1653    4.1 of [RFC5226]), and MUST conform to the purpose of transfer coding
1654    defined in this specification.
1655
1656
1657Section 8.4.2., paragraph 1:
1658OLD:
1659
1660    The HTTP Transfer Coding Registry shall be updated with the
1661    registrations below:
1662
1663NEW:
1664
1665    The "HTTP Transfer Coding Registry" has been updated with the
1666    registrations below:
1667
1668
1669Section 8.5., paragraph 1:
1670OLD:
1671
1672    IANA maintains the registry of HTTP Content Codings at
1673    <http://www.iana.org/assignments/http-parameters>.
1674
1675NEW:
1676
1677    IANA maintains the "HTTP Content Coding Registry" at
1678    <http://www.iana.org/assignments/http-parameters>.
1679
1680
1681Section 8.5., paragraph 2:
1682OLD:
1683
1684    The HTTP Content Codings Registry shall be updated with the
1685    registrations below:
1686
1687NEW:
1688
1689    The "HTTP Content Codings Registry" has been updated with the
1690    registrations below:
1691
1692
1693Section 8.6., paragraph 1:
1694OLD:
1695
1696    The HTTP Upgrade Token Registry defines the name space for protocol-
1697    name tokens used to identify protocols in the Upgrade header field.
1698    The registry is maintained at
1699    <http://www.iana.org/assignments/http-upgrade-tokens>.
1700
1701NEW:
1702
1703    The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
1704    defines the namespace for protocol-name tokens used to identify
1705    protocols in the Upgrade header field.  The registry is maintained at
1706    <http://www.iana.org/assignments/http-upgrade-tokens>.
1707
1708
1709Section 8.6.2., paragraph 1:
1710OLD:
1711
1712    The "HTTP" entry in the HTTP Upgrade Token Registry shall be updated
1713    with the registration below:
1714
1715NEW:
1716
1717    The "HTTP" entry in the "HTTP Upgrade Token" registry shall be
1718    updated with the registration below:
1719
1720
1721Section 9.1., paragraph 3:
1722OLD:
1723
1724    When a registered name is used in the authority component, the "http"
1725    URI scheme (Section 2.7.1) relies on the user's local name resolution
1726    service to determine where it can find authoritative responses.  This
1727    means that any attack on a user's network host table, cached names,
1728    or name resolution libraries becomes an avenue for attack on
1729    establishing authority.  Likewise, the user's choice of server for
1730    Domain Name Service (DNS), and the hierarchy of servers from which it
1731    obtains resolution results, could impact the authenticity of address
1732    mappings; DNSSEC ([RFC4033]) is one way to improve authenticity.
1733
1734NEW:
1735
1736    When a registered name is used in the authority component, the "http"
1737    URI scheme (Section 2.7.1) relies on the user's local name resolution
1738    service to determine where it can find authoritative responses.  This
1739    means that any attack on a user's network host table, cached names,
1740    or name resolution libraries becomes an avenue for attack on
1741    establishing authority.  Likewise, the user's choice of server for
1742    Domain Name Service (DNS), and the hierarchy of servers from which it
1743    obtains resolution results, could impact the authenticity of address
1744    mappings; DNS Security Extensions (DNSSEC) ([RFC4033]) is one way to
1745    improve authenticity.
1746
1747
1748Section 9.2., paragraph 1:
1749OLD:
1750
1751    By their very nature, HTTP intermediaries are men-in-the-middle, and
1752    thus represent an opportunity for man-in-the-middle attacks.
1753    Compromise of the systems on which the intermediaries run can result
1754    in serious security and privacy problems.  Intermediaries might have
1755    access to security-related information, personal information about
1756    individual users and organizations, and proprietary information
1757    belonging to users and content providers.  A compromised
1758    intermediary, or an intermediary implemented or configured without
1759    regard to security and privacy considerations, might be used in the
1760    commission of a wide range of potential attacks.
1761
1762NEW:
1763
1764    By their very nature, HTTP intermediaries are men in the middle and,
1765    thus, represent an opportunity for man-in-the-middle attacks.
1766    Compromise of the systems on which the intermediaries run can result
1767    in serious security and privacy problems.  Intermediaries might have
1768    access to security-related information, personal information about
1769    individual users and organizations, and proprietary information
1770    belonging to users and content providers.  A compromised
1771    intermediary, or an intermediary implemented or configured without
1772    regard to security and privacy considerations, might be used in the
1773    commission of a wide range of potential attacks.
1774
1775
1776Section 9.3., paragraph 4:
1777OLD:
1778
1779    Recipients ought to carefully limit the extent to which they process
1780    other protocol elements, including (but not limited to) request
1781    methods, response status phrases, header field-names, numeric values,
1782    and body chunks.  Failure to limit such processing can result in
1783    buffer overflows, arithmetic overflows, or increased vulnerability to
1784    denial of service attacks.
1785
1786NEW:
1787
1788    Recipients ought to carefully limit the extent to which they process
1789    other protocol elements, including (but not limited to) request
1790    methods, response status phrases, header field-names, numeric values,
1791    and body chunks.  Failure to limit such processing can result in
1792    buffer overflows, arithmetic overflows, or increased vulnerability to
1793    denial-of-service attacks.
1794
1795
1796Section 9.6., paragraph 2:
1797OLD:
1798
1799    User agents are encouraged to implement configurable means for
1800    detecting and reporting failures of message integrity such that those
1801    means can be enabled within environments for which integrity is
1802    necessary.  For example, a browser being used to view medical history
1803    or drug interaction information needs to indicate to the user when
1804    such information is detected by the protocol to be incomplete,
1805    expired, or corrupted during transfer.  Such mechanisms might be
1806    selectively enabled via user agent extensions or the presence of
1807    message integrity metadata in a response.  At a minimum, user agents
1808    ought to provide some indication that allows a user to distinguish
1809    between a complete and incomplete response message (Section 3.4) when
1810    such verification is desired.
1811
1812NEW:
1813
1814    User agents are encouraged to implement configurable means for
1815    detecting and reporting failures of message integrity such that those
1816    means can be enabled within environments for which integrity is
1817    necessary.  For example, a browser being used to view medical history
1818    or drug interaction information needs to indicate to the user when
1819    such information is detected by the protocol to be incomplete,
1820    expired, or corrupted during transfer.  Such mechanisms might be
1821    selectively enabled via user-agent extensions or the presence of
1822    message integrity metadata in a response.  At a minimum, user agents
1823    ought to provide some indication that allows a user to distinguish
1824    between a complete and incomplete response message (Section 3.4) when
1825    such verification is desired.
1826
1827
1828Section 9.8., paragraph 2:
1829OLD:
1830
1831    HTTP log information is confidential in nature; its handling is often
1832    constrained by laws and regulations.  Log information needs to be
1833    securely stored and appropriate guidelines followed for its analysis.
1834    Anonymization of personal information within individual entries
1835    helps, but is generally not sufficient to prevent real log traces
1836    from being re-identified based on correlation with other access
1837    characteristics.  As such, access traces that are keyed to a specific
1838    client are unsafe to publish even if the key is pseudonymous.
1839
1840NEW:
1841
1842    HTTP log information is confidential in nature; its handling is often
1843    constrained by laws and regulations.  Log information needs to be
1844    securely stored and appropriate guidelines followed for its analysis.
1845    Anonymization of personal information within individual entries
1846    helps, but it is generally not sufficient to prevent real log traces
1847    from being re-identified based on correlation with other access
1848    characteristics.  As such, access traces that are keyed to a specific
1849    client are unsafe to publish even if the key is pseudonymous.
1850
1851
1852Section 10., paragraph 1:
1853OLD:
1854
1855    This edition of HTTP/1.1 builds on the many contributions that went
1856    into RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including
1857    substantial contributions made by the previous authors, editors, and
1858    working group chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding,
1859    Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter,
1860    and Paul J. Leach.  Mark Nottingham oversaw this effort as working
1861    group chair.
1862
1863NEW:
1864
1865    This edition of HTTP/1.1 builds on the many contributions that went
1866    into RFC 1945, RFC 2068, RFC 2145, and RFC 2616, including
1867    substantial contributions made by the previous authors, editors, and
1868    Working Group Chairs: Tim Berners-Lee, Ari Luotonen, Roy T. Fielding,
1869    Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter,
1870    and Paul J. Leach.  Mark Nottingham oversaw this effort as Working
1871    Group Chair.
1872
1873
1874Section 11.1., paragraph 1:
1875OLD:
1876
1877    [RFC0793]     Postel, J., "Transmission Control Protocol", STD 7,
1878                  RFC 793, September 1981.
1879 
1880    [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
1881                  Format Specification version 3.3", RFC 1950, May 1996.
1882
1883NEW:
1884
1885    [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
1886                  Format Specification version 3.3", RFC 1950, May 1996.
1887
1888
1889Section 11.1., paragraph 7:
1890OLD:
1891
1892    [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1893                  Transfer Protocol (HTTP/1.1): Semantics and Content",
1894                  draft-ietf-httpbis-p2-semantics-latest (work in
1895                  progress), May 2014.
1896
1897NEW:
1898
1899    [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1900                  Transfer Protocol (HTTP/1.1): Semantics and Content",
1901                  RFC 7231, May 2014.
1902
1903
1904Section 11.1., paragraph 8:
1905OLD:
1906
1907    [RFC7232]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1908                  Transfer Protocol (HTTP/1.1): Conditional Requests",
1909                  draft-ietf-httpbis-p4-conditional-latest (work in
1910                  progress), May 2014.
1911
1912NEW:
1913
1914    [RFC7232]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1915                  Transfer Protocol (HTTP/1.1): Conditional Requests",
1916                  RFC 7232, May 2014.
1917
1918
1919Section 11.1., paragraph 9:
1920OLD:
1921
1922    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1923                  "Hypertext Transfer Protocol (HTTP/1.1): Range
1924                  Requests", draft-ietf-httpbis-p5-range-latest (work in
1925                  progress), May 2014.
1926
1927NEW:
1928
1929    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1930                  "Hypertext Transfer Protocol (HTTP/1.1): Range
1931                  Requests", RFC 7233, May 2014.
1932
1933
1934Section 11.1., paragraph 10:
1935OLD:
1936
1937    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1938                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1939                  draft-ietf-httpbis-p6-cache-latest (work in progress),
1940                  May 2014.
1941
1942NEW:
1943
1944    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1945                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1946                  RFC 7234, May 2014.
1947
1948
1949Section 11.1., paragraph 11:
1950OLD:
1951
1952    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1953                  Transfer Protocol (HTTP/1.1): Authentication",
1954                  draft-ietf-httpbis-p7-auth-latest (work in progress),
1955                  May 2014.
1956
1957NEW:
1958
1959    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1960                  Transfer Protocol (HTTP/1.1): Authentication",
1961                  RFC 7235, May 2014.
1962 
1963    [RFC793]      Postel, J., "Transmission Control Protocol", STD 7,
1964                  RFC 793, September 1981.
1965
1966
1967Section 11.1., paragraph 13:
1968OLD:
1969
1970    [Welch]       Welch, T., "A Technique for High Performance Data
1971                  Compression", IEEE Computer 17(6), June 1984.
1972
1973NEW:
1974
1975    [Welch]       Welch, T., "A Technique for High-Performance Data
1976                  Compression", IEEE Computer 17(6), June 1984.
1977
1978
1979Appendix A., paragraph 1:
1980OLD:
1981
1982    HTTP has been in use since 1990.  The first version, later referred
1983    to as HTTP/0.9, was a simple protocol for hypertext data transfer
1984    across the Internet, using only a single request method (GET) and no
1985    metadata.  HTTP/1.0, as defined by [RFC1945], added a range of
1986    request methods and MIME-like messaging, allowing for metadata to be
1987    transferred and modifiers placed on the request/response semantics.
1988    However, HTTP/1.0 did not sufficiently take into consideration the
1989    effects of hierarchical proxies, caching, the need for persistent
1990    connections, or name-based virtual hosts.  The proliferation of
1991    incompletely-implemented applications calling themselves "HTTP/1.0"
1992    further necessitated a protocol version change in order for two
1993    communicating applications to determine each other's true
1994    capabilities.
1995
1996NEW:
1997
1998    HTTP has been in use since 1990.  The first version, later referred
1999    to as HTTP/0.9, was a simple protocol for hypertext data transfer
2000    across the Internet, using only a single request method (GET) and no
2001    metadata.  HTTP/1.0, as defined by [RFC1945], added a range of
2002    request methods and MIME-like messaging, allowing for metadata to be
2003    transferred and modifiers placed on the request/response semantics.
2004    However, HTTP/1.0 did not sufficiently take into consideration the
2005    effects of hierarchical proxies, caching, the need for persistent
2006    connections, or name-based virtual hosts.  The proliferation of
2007    incompletely implemented applications calling themselves "HTTP/1.0"
2008    further necessitated a protocol version change in order for two
2009    communicating applications to determine each other's true
2010    capabilities.
2011
2012
2013Appendix A., paragraph 2:
2014OLD:
2015
2016    HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
2017    requirements that enable reliable implementations, adding only those
2018    features that can either be safely ignored by an HTTP/1.0 recipient
2019    or only sent when communicating with a party advertising conformance
2020    with HTTP/1.1.
2021
2022NEW:
2023
2024    HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
2025    requirements that enable reliable implementations, adding only those
2026    features that can either be safely ignored by an HTTP/1.0 recipient
2027    or only be sent when communicating with a party advertising
2028    conformance with HTTP/1.1.
2029
2030
2031Appendix A., paragraph 7:
2032OLD:
2033
2034 A.1.1.  Multi-homed Web Servers
2035
2036NEW:
2037
2038 A.1.1.  Multihomed Web Servers
2039
2040
2041Section 19.7.1, paragraph 8:
2042OLD:
2043
2044    HTTP's approach to error handling has been explained.  (Section 2.5)
2045
2046NEW:
2047
2048    HTTP's approach to error handling has been explained (Section 2.5).
2049
2050
2051Section 19.7.1, paragraph 9:
2052OLD:
2053
2054    The HTTP-version ABNF production has been clarified to be case-
2055    sensitive.  Additionally, version numbers has been restricted to
2056    single digits, due to the fact that implementations are known to
2057    handle multi-digit version numbers incorrectly.  (Section 2.6)
2058
2059NEW:
2060
2061    The HTTP-version ABNF production has been clarified to be case
2062    sensitive.  Additionally, version numbers have been restricted to
2063    single digits, due to the fact that implementations are known to
2064    handle multi-digit version numbers incorrectly (Section 2.6).
2065
2066
2067Section 19.7.1, paragraph 10:
2068OLD:
2069
2070    Userinfo (i.e., username and password) are now disallowed in HTTP and
2071    HTTPS URIs, because of security issues related to their transmission
2072    on the wire.  (Section 2.7.1)
2073
2074NEW:
2075
2076    Userinfo (i.e., username and password) are now disallowed in HTTP and
2077    HTTPS URIs, because of security issues related to their transmission
2078    on the wire (Section 2.7.1).
2079
2080
2081Section 19.7.1, paragraph 11:
2082OLD:
2083
2084    The HTTPS URI scheme is now defined by this specification;
2085    previously, it was done in Section 2.4 of [RFC2818].  Furthermore, it
2086    implies end-to-end security.  (Section 2.7.2)
2087
2088NEW:
2089
2090    The HTTPS URI scheme is now defined by this specification;
2091    previously, it was defined in Section 2.4 of [RFC2818].  Furthermore,
2092    it implies end-to-end security (Section 2.7.2).
2093
2094
2095Section 19.7.1, paragraph 12:
2096OLD:
2097
2098    HTTP messages can be (and often are) buffered by implementations;
2099    despite it sometimes being available as a stream, HTTP is
2100    fundamentally a message-oriented protocol.  Minimum supported sizes
2101    for various protocol elements have been suggested, to improve
2102    interoperability.  (Section 3)
2103
2104NEW:
2105
2106    HTTP messages can be (and often are) buffered by implementations;
2107    despite it sometimes being available as a stream, HTTP is
2108    fundamentally a message-oriented protocol.  Minimum supported sizes
2109    for various protocol elements have been suggested, to improve
2110    interoperability (Section 3).
2111
2112
2113Section 19.7.1, paragraph 13:
2114OLD:
2115
2116    Invalid whitespace around field-names is now required to be rejected,
2117    because accepting it represents a security vulnerability.  The ABNF
2118    productions defining header fields now only list the field value.
2119    (Section 3.2)
2120
2121NEW:
2122
2123    Invalid whitespace around field-names is now required to be rejected,
2124    because accepting it represents a security vulnerability.  The ABNF
2125    productions defining header fields now only list the field value
2126    (Section 3.2).
2127
2128
2129Section 19.7.1, paragraph 14:
2130OLD:
2131
2132    Rules about implicit linear whitespace between certain grammar
2133    productions have been removed; now whitespace is only allowed where
2134    specifically defined in the ABNF.  (Section 3.2.3)
2135
2136NEW:
2137
2138    Rules about implicit linear whitespace between certain grammar
2139    productions have been removed; now whitespace is only allowed where
2140    specifically defined in the ABNF (Section 3.2.3).
2141
2142
2143Section 19.7.1, paragraph 15:
2144OLD:
2145
2146    Header fields that span multiple lines ("line folding") are
2147    deprecated.  (Section 3.2.4)
2148    The NUL octet is no longer allowed in comment and quoted-string text,
2149    and handling of backslash-escaping in them has been clarified.  The
2150    quoted-pair rule no longer allows escaping control characters other
2151    than HTAB.  Non-ASCII content in header fields and the reason phrase
2152    has been obsoleted and made opaque (the TEXT rule was removed).
2153    (Section 3.2.6)
2154
2155NEW:
2156
2157    Header fields that span multiple lines ("line folding") are
2158    deprecated (Section 3.2.4).
2159 
2160    The NUL octet is no longer allowed in comment and quoted-string text,
2161    and handling of backslash-escaping in them has been clarified.  The
2162    quoted-pair rule no longer allows escaping control characters other
2163    than HTAB.  Non-US-ASCII content in header fields and the reason
2164    phrase has been obsoleted and made opaque (the TEXT rule was removed)
2165    (Section 3.2.6).
2166
2167
2168Section 19.7.1, paragraph 16:
2169OLD:
2170
2171    Bogus "Content-Length" header fields are now required to be handled
2172    as errors by recipients.  (Section 3.3.2)
2173
2174NEW:
2175
2176    Bogus "Content-Length" header fields are now required to be handled
2177    as errors by recipients (Section 3.3.2).
2178
2179
2180Section 19.7.1, paragraph 17:
2181OLD:
2182
2183    The algorithm for determining the message body length has been
2184    clarified to indicate all of the special cases (e.g., driven by
2185    methods or status codes) that affect it, and that new protocol
2186    elements cannot define such special cases.  CONNECT is a new, special
2187    case in determining message body length. "multipart/byteranges" is no
2188    longer a way of determining message body length detection.
2189    (Section 3.3.3)
2190
2191NEW:
2192
2193    The algorithm for determining the message body length has been
2194    clarified to indicate all of the special cases (e.g., driven by
2195    methods or status codes) that affect it, and that new protocol
2196    elements cannot define such special cases.  CONNECT is a new, special
2197    case in determining message body length. "multipart/byteranges" is no
2198    longer a way of determining message body length detection
2199    (Section 3.3.3).
2200
2201
2202Section 19.7.1, paragraph 18:
2203OLD:
2204
2205    The "identity" transfer coding token has been removed.  (Sections 3.3
2206    and 4)
2207
2208NEW:
2209
2210    The "identity" transfer coding token has been removed (Sections 3.3
2211    and 4).
2212
2213
2214Section 19.7.1, paragraph 19:
2215OLD:
2216
2217    Chunk length does not include the count of the octets in the chunk
2218    header and trailer.  Line folding in chunk extensions is disallowed.
2219    (Section 4.1)
2220
2221NEW:
2222
2223    Chunk length does not include the count of the octets in the chunk
2224    header and trailer.  Line folding in chunk extensions is disallowed
2225    (Section 4.1).
2226
2227
2228Section 19.7.1, paragraph 20:
2229OLD:
2230
2231    The meaning of the "deflate" content coding has been clarified.
2232    (Section 4.2.2)
2233
2234NEW:
2235
2236    The meaning of the "deflate" content coding has been clarified
2237    (Section 4.2.2).
2238
2239
2240Section 19.7.1, paragraph 21:
2241OLD:
2242
2243    The segment + query components of RFC 3986 have been used to define
2244    the request-target, instead of abs_path from RFC 1808.  The asterisk-
2245    form of the request-target is only allowed with the OPTIONS method.
2246    (Section 5.3)
2247
2248NEW:
2249
2250    The segment + query components of RFC 3986 have been used to define
2251    the request-target, instead of abs_path from RFC 1808.  The asterisk-
2252    form of the request-target is only allowed with the OPTIONS method
2253    (Section 5.3).
2254
2255
2256Section 19.7.1, paragraph 22:
2257OLD:
2258
2259    The term "Effective Request URI" has been introduced.  (Section 5.5)
2260
2261NEW:
2262
2263    The term "Effective Request URI" has been introduced (Section 5.5).
2264
2265
2266Section 19.7.1, paragraph 23:
2267OLD:
2268
2269    Gateways do not need to generate Via header fields anymore.
2270    (Section 5.7.1)
2271
2272NEW:
2273
2274    Gateways do not need to generate Via header fields anymore
2275    (Section 5.7.1).
2276
2277
2278Section 19.7.1, paragraph 24:
2279OLD:
2280
2281    Exactly when "close" connection options have to be sent has been
2282    clarified.  Also, "hop-by-hop" header fields are required to appear
2283    in the Connection header field; just because they're defined as hop-
2284    by-hop in this specification doesn't exempt them.  (Section 6.1)
2285
2286NEW:
2287
2288    Exactly when "close" connection options have to be sent has been
2289    clarified.  Also, "hop-by-hop" header fields are required to appear
2290    in the Connection header field; just because they're defined as hop-
2291    by-hop in this specification doesn't exempt them (Section 6.1).
2292
2293
2294Section 19.7.1, paragraph 25:
2295OLD:
2296
2297    The limit of two connections per server has been removed.  An
2298    idempotent sequence of requests is no longer required to be retried.
2299    The requirement to retry requests under certain circumstances when
2300    the server prematurely closes the connection has been removed.  Also,
2301    some extraneous requirements about when servers are allowed to close
2302    connections prematurely have been removed.  (Section 6.3)
2303
2304NEW:
2305
2306    The limit of two connections per server has been removed.  An
2307    idempotent sequence of requests is no longer required to be retried.
2308    The requirement to retry requests under certain circumstances when
2309    the server prematurely closes the connection has been removed.  Also,
2310    some extraneous requirements about when servers are allowed to close
2311    connections prematurely have been removed (Section 6.3).
2312
2313
2314Section 19.7.1, paragraph 26:
2315OLD:
2316
2317    The semantics of the Upgrade header field is now defined in responses
2318    other than 101 (this was incorporated from [RFC2817]).  Furthermore,
2319    the ordering in the field value is now significant.  (Section 6.7)
2320
2321NEW:
2322
2323    The semantics of the Upgrade header field is now defined in responses
2324    other than 101 (this was incorporated from [RFC2817]).  Furthermore,
2325    the ordering in the field value is now significant (Section 6.7).
2326
2327
2328Section 19.7.1, paragraph 27:
2329OLD:
2330
2331    Empty list elements in list productions (e.g., a list header field
2332    containing ", ,") have been deprecated.  (Section 7)
2333
2334NEW:
2335
2336    Empty list elements in list productions (e.g., a list header field
2337    containing ", ,") have been deprecated (Section 7).
2338
2339
2340Section 19.7.1, paragraph 28:
2341OLD:
2342
2343    Registration of Transfer Codings now requires IETF Review
2344    (Section 8.4)
2345
2346NEW:
2347
2348    Registration of Transfer Codings now requires IETF Review
2349    (Section 8.4).
2350
2351
2352Section 19.7.1, paragraph 29:
2353OLD:
2354
2355    This specification now defines the Upgrade Token Registry, previously
2356    defined in Section 7.2 of [RFC2817].  (Section 8.6)
2357
2358NEW:
2359
2360    This specification now defines the "HTTP Upgrade Tokens" registry,
2361    previously defined in Section 7.2 of [RFC2817] (Section 8.6).
2362
2363
2364Section 19.7.1, paragraph 30:
2365OLD:
2366
2367    The expectation to support HTTP/0.9 requests has been removed.
2368    (Appendix A)
2369
2370NEW:
2371
2372    The expectation to support HTTP/0.9 requests has been removed
2373    (Appendix A).
2374
2375
2376Section 19.7.1, paragraph 31:
2377OLD:
2378
2379    Issues with the Keep-Alive and Proxy-Connection header fields in
2380    requests are pointed out, with use of the latter being discouraged
2381    altogether.  (Appendix A.1.2)
2382
2383NEW:
2384
2385    Issues with the Keep-Alive and Proxy-Connection header fields in
2386    requests are pointed out, with use of the latter being discouraged
2387    altogether (Appendix A.1.2).
2388
2389
2390Appendix B., paragraph 7:
2391OLD:
2392
2393    URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
2394    Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
2395    Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
2396     ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
2397     comment ] ) ] )
2398
2399NEW:
2400
2401    URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
2402    Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
2403 
2404    Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
2405     ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
2406     comment ] ) ] )
2407
2408
2409Appendix B., paragraph 15:
2410OLD:
2411
2412    partial-URI = relative-part [ "?" query ]
2413    path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
2414    port = <port, defined in [RFC3986], Section 3.2.3>
2415    protocol = protocol-name [ "/" protocol-version ]
2416    protocol-name = token
2417    protocol-version = token
2418    pseudonym = token
2419 
2420    qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
2421     / %x5D-7E ; ']'-'~'
2422     / obs-text
2423    query = <query, defined in [RFC3986], Section 3.4>
2424    quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
2425    quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
2426
2427NEW:
2428
2429    partial-URI = relative-part [ "?" query ]
2430    path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
2431    port = <port, defined in [RFC3986], Section 3.2.3>
2432    protocol = protocol-name [ "/" protocol-version ]
2433    protocol-name = token
2434    protocol-version = token
2435    pseudonym = token
2436    qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
2437     / %x5D-7E ; ']'-'~'
2438     / obs-text
2439    query = <query, defined in [RFC3986], Section 3.4>
2440    quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
2441    quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
2442
2443
2444Appendix B., paragraph 24:
2445OLD:
2446
2447    D
2448       deflate (Coding Format)  38
2449       Delimiters  26
2450       downstream  9
2451
2452NEW:
2453
2454    D
2455       deflate (Coding Format)  38
2456       Delimiters  26
2457       downstream  10
2458
2459
2460Appendix B., paragraph 26:
2461OLD:
2462
2463    G
2464       gateway  10
2465       Grammar
2466          absolute-form  41-42
2467          absolute-path  16
2468          absolute-URI  16
2469          ALPHA  6
2470          asterisk-form  41-42
2471          authority  16
2472          authority-form  41-42
2473          BWS  24
2474          chunk  35
2475          chunk-data  35
2476          chunk-ext  35-36
2477          chunk-ext-name  36
2478          chunk-ext-val  36
2479          chunk-size  35
2480          chunked-body  35-36
2481          comment  27
2482          Connection  51
2483          connection-option  51
2484          Content-Length  30
2485          CR  6
2486          CRLF  6
2487          ctext  27
2488          CTL  6
2489          DIGIT  6
2490          DQUOTE  6
2491          field-content  22
2492          field-name  22, 39
2493          field-value  22
2494          field-vchar  22
2495          fragment  16
2496          header-field  22, 36
2497          HEXDIG  6
2498          Host  43
2499          HTAB  6
2500          HTTP-message  19
2501          HTTP-name  13
2502          http-URI  16
2503          HTTP-version  13
2504          https-URI  18
2505          last-chunk  35
2506          LF  6
2507          message-body  27
2508          method  21
2509          obs-fold  22
2510          obs-text  27
2511          OCTET  6
2512          origin-form  41
2513          OWS  24
2514          partial-URI  16
2515          port  16
2516          protocol-name  47
2517          protocol-version  47
2518          pseudonym  47
2519          qdtext  27
2520          query  16
2521          quoted-pair  27
2522          quoted-string  27
2523          rank  38
2524          reason-phrase  22
2525          received-by  47
2526          received-protocol  47
2527          request-line  21
2528          request-target  41
2529          RWS  24
2530          scheme  16
2531          segment  16
2532          SP  6
2533          start-line  20
2534          status-code  22
2535          status-line  22
2536          t-codings  38
2537          t-ranking  38
2538          tchar  27
2539          TE  38
2540          token  27
2541          Trailer  39
2542          trailer-part  35-36
2543          transfer-coding  35
2544          Transfer-Encoding  28
2545          transfer-extension  35
2546          transfer-parameter  35
2547          Upgrade  56
2548          uri-host  16
2549          URI-reference  16
2550          VCHAR  6
2551          Via  47
2552       gzip (Coding Format)  38
2553
2554NEW:
2555
2556    G
2557       gateway  10
2558       Grammar
2559          absolute-form  41-42
2560          absolute-path  16
2561          absolute-URI  16
2562          ALPHA  6
2563          asterisk-form  41-42
2564          authority  16
2565          authority-form  41-42
2566          BWS  24
2567          chunk  35
2568          chunk-data  35
2569          chunk-ext  35-36
2570          chunk-ext-name  36
2571          chunk-ext-val  36
2572          chunk-size  35
2573          chunked-body  35-36
2574          comment  27
2575          Connection  51
2576          connection-option  51
2577          Content-Length  30
2578          CR  6
2579          CRLF  6
2580          ctext  27
2581          CTL  6
2582          DIGIT  6
2583          DQUOTE  6
2584          field-content  22
2585          field-name  22, 39
2586          field-value  22
2587          field-vchar  22
2588          fragment  16
2589          header-field  22, 36
2590          HEXDIG  6
2591          Host  43
2592          HTAB  6
2593          HTTP-message  19
2594          HTTP-name  14
2595          http-URI  16
2596          HTTP-version  14
2597          https-URI  18
2598          last-chunk  35
2599          LF  6
2600          message-body  27
2601          method  21
2602          obs-fold  22
2603          obs-text  27
2604          OCTET  6
2605          origin-form  41
2606          OWS  24
2607          partial-URI  16
2608          port  16
2609          protocol-name  47
2610          protocol-version  47
2611          pseudonym  47
2612          qdtext  27
2613          query  16
2614          quoted-pair  27
2615          quoted-string  27
2616          rank  38
2617          reason-phrase  22
2618          received-by  47
2619          received-protocol  47
2620          request-line  21
2621          request-target  41
2622          RWS  24
2623          scheme  16
2624          segment  16
2625          SP  6
2626          start-line  20
2627          status-code  22
2628          status-line  22
2629          t-codings  38
2630          t-ranking  38
2631          tchar  27
2632          TE  38
2633          token  27
2634          Trailer  39
2635          trailer-part  35-36
2636          transfer-coding  35
2637          Transfer-Encoding  28
2638          transfer-extension  35
2639          transfer-parameter  35
2640          Upgrade  56
2641          uri-host  16
2642          URI-reference  16
2643          VCHAR  6
2644          Via  47
2645       gzip (Coding Format)  38
2646
2647
2648Appendix B., paragraph 28:
2649OLD:
2650
2651    I
2652       inbound  9
2653       interception proxy  11
2654       intermediary  9
2655
2656NEW:
2657
2658    I
2659       inbound  10
2660       interception proxy  11
2661       intermediary  9
2662
2663
2664Appendix B., paragraph 31:
2665OLD:
2666
2667    O
2668       origin server  7
2669       origin-form (of request-target)  41
2670       outbound  9
2671
2672NEW:
2673
2674    O
2675       origin server  7
2676       origin-form (of request-target)  41
2677       outbound  10
2678
2679
2680Appendix B., paragraph 36:
2681OLD:
2682
2683    U
2684       Upgrade header field  56
2685       upstream  9
2686       URI scheme
2687          http  16
2688          https  18
2689       user agent  7
2690
2691NEW:
2692
2693    U
2694       Upgrade header field  56
2695       upstream  10
2696       URI scheme
2697          http  16
2698          https  18
2699       user agent  7
2700
2701
2702Section 345, paragraph 1:
2703OLD:
2704
2705    EMail: fielding@gbiv.com
2706    URI:   http://roy.gbiv.com/
2707 
2708    Julian F. Reschke (editor)
2709    greenbytes GmbH
2710    Hafenweg 16
2711    Muenster, NW  48155
2712    Germany
2713
2714NEW:
2715
2716    EMail: fielding@gbiv.com
2717    URI:   http://roy.gbiv.com/
2718    Julian F. Reschke (editor)
2719    greenbytes GmbH
2720    Hafenweg 16
2721    Muenster, NW  48155
2722    Germany
2723
Note: See TracBrowser for help on using the repository browser.