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

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

quote terms (#553)

File size: 83.8 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 Timeouts  . . . . . . . . . . . . . . . . . . 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.3., paragraph 7:
355OLD:
356
357    All HTTP requirements applicable to an origin server also apply to
358    the outbound communication of a gateway.  A gateway communicates with
359    inbound servers using any protocol that it desires, including private
360    extensions to HTTP that are outside the scope of this specification.
361    However, an HTTP-to-HTTP gateway that wishes to interoperate with
362    third-party HTTP servers ought to conform to user agent requirements
363    on the gateway's inbound connection.
364
365NEW:
366
367    All HTTP requirements applicable to an origin server also apply to
368    the outbound communication of a gateway.  A gateway communicates with
369    inbound servers using any protocol that it desires, including private
370    extensions to HTTP that are outside the scope of this specification.
371    However, an HTTP-to-HTTP gateway that wishes to interoperate with
372    third-party HTTP servers ought to conform to user-agent requirements
373    on the gateway's inbound connection.
374
375
376Section 2.3., paragraph 11:
377OLD:
378
379    HTTP is defined as a stateless protocol, meaning that each request
380    message can be understood in isolation.  Many implementations depend
381    on HTTP's stateless design in order to reuse proxied connections or
382    dynamically load-balance requests across multiple servers.  Hence, a
383    server MUST NOT assume that two requests on the same connection are
384    from the same user agent unless the connection is secured and
385    specific to that agent.  Some non-standard HTTP extensions (e.g.,
386    [RFC4559]) have been known to violate this requirement, resulting in
387    security and interoperability problems.
388
389NEW:
390
391    HTTP is defined as a stateless protocol, meaning that each request
392    message can be understood in isolation.  Many implementations depend
393    on HTTP's stateless design in order to reuse proxied connections or
394    dynamically load balance requests across multiple servers.  Hence, a
395    server MUST NOT assume that two requests on the same connection are
396    from the same user agent unless the connection is secured and
397    specific to that agent.  Some non-standard HTTP extensions (e.g.,
398    [RFC4559]) have been known to violate this requirement, resulting in
399    security and interoperability problems.
400
401
402Section 2.4., paragraph 5:
403OLD:
404
405    There are a wide variety of architectures and configurations of
406    caches deployed across the World Wide Web and inside large
407    organizations.  These include national hierarchies of proxy caches to
408    save transoceanic bandwidth, collaborative systems that broadcast or
409    multicast cache entries, archives of pre-fetched cache entries for
410    use in off-line or high-latency environments, and so on.
411
412NEW:
413
414    There is a wide variety of architectures and configurations of caches
415    deployed across the World Wide Web and inside large organizations.
416    These include national hierarchies of proxy caches to save
417    transoceanic bandwidth, collaborative systems that broadcast or
418    multicast cache entries, archives of pre-fetched cache entries for
419    use in off-line or high-latency environments, and so on.
420
421
422Section 2.5., paragraph 5:
423OLD:
424
425    When a received protocol element is parsed, the recipient MUST be
426    able to parse any value of reasonable length that is applicable to
427    the recipient's role and matches the grammar defined by the
428    corresponding ABNF rules.  Note, however, that some received protocol
429    elements might not be parsed.  For example, an intermediary
430    forwarding a message might parse a header-field into generic field-
431    name and field-value components, but then forward the header field
432    without further parsing inside the field-value.
433
434NEW:
435
436    When a received protocol element is parsed, the recipient MUST be
437    able to parse any value of reasonable length that is applicable to
438    the recipient's role and that matches the grammar defined by the
439    corresponding ABNF rules.  Note, however, that some received protocol
440    elements might not be parsed.  For example, an intermediary
441    forwarding a message might parse a header-field into generic field-
442    name and field-value components, but then forward the header field
443    without further parsing inside the field-value.
444
445
446Section 2.6., paragraph 2:
447OLD:
448
449    The version of an HTTP message is indicated by an HTTP-version field
450    in the first line of the message.  HTTP-version is case-sensitive.
451
452NEW:
453
454    The version of an HTTP message is indicated by an HTTP-version field
455    in the first line of the message.  HTTP-version is case sensitive.
456
457
458Section 2.6., paragraph 3:
459OLD:
460
461      HTTP-version  = HTTP-name "/" DIGIT "." DIGIT
462      HTTP-name     = %x48.54.54.50 ; "HTTP", case-sensitive
463
464NEW:
465
466      HTTP-version  = HTTP-name "/" DIGIT "." DIGIT
467      HTTP-name     = %x48.54.54.50 ; "HTTP", case sensitive
468
469
470Section 2.6., paragraph 7:
471OLD:
472
473    New header fields can be introduced without changing the protocol
474    version if their defined semantics allow them to be safely ignored by
475    recipients that do not recognize them.  Header field extensibility is
476    discussed in Section 3.2.1.
477
478NEW:
479
480    New header fields can be introduced without changing the protocol
481    version if their defined semantics allow them to be safely ignored by
482    recipients that do not recognize them.  Header-field extensibility is
483    discussed in Section 3.2.1.
484
485
486Section 2.6., paragraph 14:
487OLD:
488
489    When an HTTP message is received with a major version number that the
490    recipient implements, but a higher minor version number than what the
491    recipient implements, the recipient SHOULD process the message as if
492    it were in the highest minor version within that major version to
493    which the recipient is conformant.  A recipient can assume that a
494    message with a higher minor version, when sent to a recipient that
495    has not yet indicated support for that higher version, is
496    sufficiently backwards-compatible to be safely processed by any
497    implementation of the same major version.
498
499NEW:
500
501    When an HTTP message is received with a major version number that the
502    recipient implements, but a higher minor version number than what the
503    recipient implements, the recipient SHOULD process the message as if
504    it were in the highest minor version within that major version to
505    which the recipient is conformant.  A recipient can assume that a
506    message with a higher minor version, when sent to a recipient that
507    has not yet indicated support for that higher version, is
508    sufficiently backwards compatible to be safely processed by any
509    implementation of the same major version.
510
511
512Section 2.7., paragraph 2:
513OLD:
514
515    The definitions of "URI-reference", "absolute-URI", "relative-part",
516    "scheme", "authority", "port", "host", "path-abempty", "segment",
517    "query", and "fragment" are adopted from the URI generic syntax.  An
518    "absolute-path" rule is defined for protocol elements that can
519    contain a non-empty path component.  (This rule differs slightly from
520    RFC 3986's path-abempty rule, which allows for an empty path to be
521    used in references, and path-absolute rule, which does not allow
522    paths that begin with "//".)  A "partial-URI" rule is defined for
523    protocol elements that can contain a relative URI but not a fragment
524    component.
525
526NEW:
527
528    The definitions of "URI-reference", "absolute-URI", "relative-part",
529    "scheme", "authority", "port", "host", "path-abempty", "segment",
530    "query", and "fragment" are adopted from the URI generic syntax.  An
531    "absolute-path" rule is defined for protocol elements that can
532    contain a non-empty path component.  (This rule differs slightly from
533    the path-abempty rule of RFC 3986, which allows for an empty path to
534    be used in references, and path-absolute rule, which does not allow
535    paths that begin with "//".)  A "partial-URI" rule is defined for
536    protocol elements that can contain a relative URI but not a fragment
537    component.
538
539
540Section 2.7.1., paragraph 1:
541OLD:
542
543    The "http" URI scheme is hereby defined for the purpose of minting
544    identifiers according to their association with the hierarchical
545    namespace governed by a potential HTTP origin server listening for
546    TCP ([RFC0793]) connections on a given port.
547
548NEW:
549
550    The "http" URI scheme is hereby defined for the purpose of minting
551    identifiers according to their association with the hierarchical
552    namespace governed by a potential HTTP origin server listening for
553    TCP ([RFC793]) connections on a given port.
554
555
556Section 2.1, paragraph 0:
557OLD:
558
559    If the port is equal to the default port for a scheme, the normal
560    form is to omit the port subcomponent.  When not being used in
561    absolute form as the request target of an OPTIONS request, an empty
562    path component is equivalent to an absolute path of "/", so the
563    normal form is to provide a path of "/" instead.  The scheme and host
564    are case-insensitive and normally provided in lowercase; all other
565    components are compared in a case-sensitive manner.  Characters other
566    than those in the "reserved" set are equivalent to their percent-
567    encoded octets: the normal form is to not encode them (see Sections
568    2.1 and 2.2 of [RFC3986]).
569
570NEW:
571
572    If the port is equal to the default port for a scheme, the normal
573    form is to omit the port subcomponent.  When not being used in
574    absolute form as the request target of an OPTIONS request, an empty
575    path component is equivalent to an absolute path of "/", so the
576    normal form is to provide a path of "/" instead.  The scheme and host
577    are case insensitive and normally provided in lowercase; all other
578    components are compared in a case-sensitive manner.  Characters other
579    than those in the "reserved" set are equivalent to their percent-
580    encoded octets: the normal form is to not encode them (see Sections
581    2.1 and 2.2 of [RFC3986]).
582
583
584Section 3.1., paragraph 1:
585OLD:
586
587    An HTTP message can either be a request from client to server or a
588    response from server to client.  Syntactically, the two types of
589    message differ only in the start-line, which is either a request-line
590    (for requests) or a status-line (for responses), and in the algorithm
591    for determining the length of the message body (Section 3.3).
592
593NEW:
594
595    An HTTP message can be either a request from client to server or a
596    response from server to client.  Syntactically, the two types of
597    message differ only in the start-line, which is either a request-line
598    (for requests) or a status-line (for responses), and in the algorithm
599    for determining the length of the message body (Section 3.3).
600
601
602Section 3.1., paragraph 2:
603OLD:
604
605    In theory, a client could receive requests and a server could receive
606    responses, distinguishing them by their different start-line formats,
607    but, in practice, servers are implemented to only expect a request (a
608    response is interpreted as an unknown or invalid request method) and
609    clients are implemented to only expect a response.
610
611NEW:
612
613    In theory, a client could receive requests and a server could receive
614    responses, distinguishing them by their different start-line formats,
615    but, in practice, servers are implemented only to expect a request (a
616    response is interpreted as an unknown or invalid request method) and
617    clients are implemented to only expect a response.
618
619
620Section 3.1.1., paragraph 1:
621OLD:
622
623    A request-line begins with a method token, followed by a single space
624    (SP), the request-target, another single space (SP), the protocol
625    version, and ending with CRLF.
626
627NEW:
628
629    A request-line begins with a method token and is followed by a single
630    space (SP), the request-target, another single space (SP), the
631    protocol version, and ends with CRLF.
632
633
634Section 3.1.1., paragraph 3:
635OLD:
636
637    The method token indicates the request method to be performed on the
638    target resource.  The request method is case-sensitive.
639
640NEW:
641
642    The method token indicates the request method to be performed on the
643    target resource.  The request method is case sensitive.
644
645
646Section 3.1.2., paragraph 1:
647OLD:
648
649    The first line of a response message is the status-line, consisting
650    of the protocol version, a space (SP), the status code, another
651    space, a possibly empty textual phrase describing the status code,
652    and ending with CRLF.
653
654NEW:
655
656    The first line of a response message is the status-line, consisting
657    of the protocol version, a space (SP), the status code, another space
658    (SP), a possibly empty textual phrase describing the status code,
659    and, finally, CRLF.
660
661
662Section 3.2.1., paragraph 4:
663OLD:
664
665    All defined header fields ought to be registered with IANA in the
666    Message Header Field Registry, as described in Section 8.3 of
667    [RFC7231].
668
669NEW:
670
671    All defined header fields ought to be registered with IANA in the
672    "Message Headers" field registry, as described in Section 8.3 of
673    [RFC7231].
674
675
676Section 3.2.2., paragraph 4:
677OLD:
678
679       Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
680       appears multiple times in a response message and does not use the
681       list syntax, violating the above requirements on multiple header
682       fields with the same name.  Since it cannot be combined into a
683       single field-value, recipients ought to handle "Set-Cookie" as a
684       special case while processing header fields.  (See Appendix A.2.3
685       of [Kri2001] for details.)
686
687NEW:
688
689       Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
690       appears multiple times in a response message and does not use the
691       list syntax, violating the above requirements on multiple header
692       fields with the same name.  Since it cannot be combined into a
693       single field-value, recipients ought to handle Set-Cookie as a
694       special case while processing header fields.  (See Appendix A.2.3
695       of [Kri2001] for details.)
696
697
698Section 3.2.3., paragraph 2:
699OLD:
700
701    The OWS rule is used where zero or more linear whitespace octets
702    might appear.  For protocol elements where optional whitespace is
703    preferred to improve readability, a sender SHOULD generate the
704    optional whitespace as a single SP; otherwise, a sender SHOULD NOT
705    generate optional whitespace except as needed to white-out invalid or
706    unwanted protocol elements during in-place message filtering.
707
708NEW:
709
710    The OWS rule is used where zero or more linear whitespace octets
711    might appear.  For protocol elements where optional whitespace is
712    preferred to improve readability, a sender SHOULD generate the
713    optional whitespace as a single SP; otherwise, a sender SHOULD NOT
714    generate optional whitespace except as needed to white out invalid or
715    unwanted protocol elements during in-place message filtering.
716
717
718Section 3.2.4., paragraph 1:
719OLD:
720
721    Messages are parsed using a generic algorithm, independent of the
722    individual header field names.  The contents within a given field
723    value are not parsed until a later stage of message interpretation
724    (usually after the message's entire header section has been
725    processed).  Consequently, this specification does not use ABNF rules
726    to define each "Field-Name: Field Value" pair, as was done in
727    previous editions.  Instead, this specification uses ABNF rules which
728    are named according to each registered field name, wherein the rule
729    defines the valid grammar for that field's corresponding field values
730    (i.e., after the field-value has been extracted from the header
731    section by a generic field parser).
732
733NEW:
734
735    Messages are parsed using a generic algorithm, independent of the
736    individual header field names.  The contents within a given field
737    value are not parsed until a later stage of message interpretation
738    (usually after the message's entire header section has been
739    processed).  Consequently, this specification does not use ABNF rules
740    to define each "field-name: field-value" pair, as was done in
741    previous editions.  Instead, this specification uses ABNF rules that
742    are named according to each registered field name, wherein the rule
743    defines the valid grammar for that field's corresponding field values
744    (i.e., after the field-value has been extracted from the header
745    section by a generic field parser).
746
747
748Section 3.2.4., paragraph 8:
749OLD:
750
751    Historically, HTTP has allowed field content with text in the ISO-
752    8859-1 [ISO-8859-1] charset, supporting other charsets only through
753    use of [RFC2047] encoding.  In practice, most HTTP header field
754    values use only a subset of the US-ASCII charset [USASCII].  Newly
755    defined header fields SHOULD limit their field values to US-ASCII
756    octets.  A recipient SHOULD treat other octets in field content (obs-
757    text) as opaque data.
758
759NEW:
760
761    Historically, HTTP has allowed field content with text in the
762    ISO-8859-1 [ISO-8859-1] charset, supporting other charsets only
763    through use of [RFC2047] encoding.  In practice, most HTTP header
764    field values use only a subset of the US-ASCII charset [USASCII].
765    Newly defined header fields SHOULD limit their field values to
766    US-ASCII octets.  A recipient SHOULD treat other octets in field
767    content (obs-text) as opaque data.
768
769
770Section 7., paragraph 1:
771OLD:
772
773    Since there is no way to distinguish a successfully completed, close-
774    delimited message from a partially-received message interrupted by
775    network failure, a server SHOULD generate encoding or length-
776    delimited messages whenever possible.  The close-delimiting feature
777    exists primarily for backwards compatibility with HTTP/1.0.
778
779NEW:
780
781    Since there is no way to distinguish a successfully completed, close-
782    delimited message from a partially received message interrupted by
783    network failure, a server SHOULD generate encoding or length-
784    delimited messages whenever possible.  The close-delimiting feature
785    exists primarily for backwards compatibility with HTTP/1.0.
786
787
788Section 4., paragraph 5:
789OLD:
790
791    All transfer-coding names are case-insensitive and ought to be
792    registered within the HTTP Transfer Coding registry, as defined in
793    Section 8.4.  They are used in the TE (Section 4.3) and Transfer-
794    Encoding (Section 3.3.1) header fields.
795
796NEW:
797
798    All transfer-coding names are case insensitive and ought to be
799    registered within the "HTTP Transfer Coding" registry, as defined in
800    Section 8.4.  They are used in the TE (Section 4.3) and Transfer-
801    Encoding (Section 3.3.1) header fields.
802
803
804Section 4.2.3., paragraph 1:
805OLD:
806
807    The "gzip" coding is an LZ77 coding with a 32 bit CRC that is
808    commonly produced by the gzip file compression program [RFC1952].  A
809    recipient SHOULD consider "x-gzip" to be equivalent to "gzip".
810
811NEW:
812
813    The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy
814    Check (CRC) that is commonly produced by the gzip file compression
815    program [RFC1952].  A recipient SHOULD consider "x-gzip" to be
816    equivalent to "gzip".
817
818
819Section 5.7.2., paragraph 6:
820OLD:
821
822    A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of
823    a message that contains a no-transform cache-control directive
824    (Section 5.2 of [RFC7234]).
825
826NEW:
827
828    A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of
829    a message that contains a no-transform Cache-Control directive
830    (Section 5.2 of [RFC7234]).
831
832
833Section 200, paragraph 0:
834OLD:
835
836    A proxy MAY transform the payload of a message that does not contain
837    a no-transform cache-control directive.  A proxy that transforms a
838    payload MUST add a Warning header field with the warn-code of 214
839    ("Transformation Applied") if one is not already in the message (see
840    Section 5.5 of [RFC7234]).  A proxy that transforms the payload of a
841    200 (OK) response can further inform downstream recipients that a
842    transformation has been applied by changing the response status code
843    to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).
844
845NEW:
846
847    A proxy MAY transform the payload of a message that does not contain
848    a no-transform Cache-Control directive.  A proxy that transforms a
849    payload MUST add a Warning header field with the warn-code of 214
850    ("Transformation Applied") if one is not already in the message (see
851    Section 5.5 of [RFC7234]).  A proxy that transforms the payload of a
852    200 (OK) response can further inform downstream recipients that a
853    transformation has been applied by changing the response status code
854    to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).
855
856
857Section 6., paragraph 1:
858OLD:
859
860    HTTP messaging is independent of the underlying transport or session-
861    layer connection protocol(s).  HTTP only presumes a reliable
862    transport with in-order delivery of requests and the corresponding
863    in-order delivery of responses.  The mapping of HTTP request and
864    response structures onto the data units of an underlying transport
865    protocol is outside the scope of this specification.
866
867NEW:
868
869    HTTP messaging is independent of the underlying transport- or
870    session-layer connection protocol(s).  HTTP only presumes a reliable
871    transport with in-order delivery of requests and the corresponding
872    in-order delivery of responses.  The mapping of HTTP request and
873    response structures onto the data units of an underlying transport
874    protocol is outside the scope of this specification.
875
876
877Section 6.1., paragraph 6:
878OLD:
879
880    Connection options are case-insensitive.
881
882NEW:
883
884    Connection options are case insensitive.
885
886
887Section 6.2., paragraph 1:
888OLD:
889
890    It is beyond the scope of this specification to describe how
891    connections are established via various transport or session-layer
892    protocols.  Each connection applies to only one transport link.
893
894NEW:
895
896    It is beyond the scope of this specification to describe how
897    connections are established via various transport- or session-layer
898    protocols.  Each connection applies to only one transport link.
899
900
901Section 6.3., paragraph 1:
902OLD:
903
904    HTTP/1.1 defaults to the use of "persistent connections", allowing
905    multiple requests and responses to be carried over a single
906    connection.  The "close" connection-option is used to signal that a
907    connection will not persist after the current request/response.  HTTP
908    implementations SHOULD support persistent connections.
909
910NEW:
911
912    HTTP/1.1 defaults to the use of "persistent connections", allowing
913    multiple requests and responses to be carried over a single
914    connection.  The "close" connection option is used to signal that a
915    connection will not persist after the current request/response.  HTTP
916    implementations SHOULD support persistent connections.
917
918
919Section 6.3., paragraph 3:
920OLD:
921
922    o  If the close connection option is present, the connection will not
923       persist after the current response; else,
924
925NEW:
926
927    o  If the "close" connection option is present, the connection will
928       not persist after the current response; else,
929
930
931Section 6.3., paragraph 7:
932OLD:
933
934    A client MAY send additional requests on a persistent connection
935    until it sends or receives a close connection option or receives an
936    HTTP/1.0 response without a "keep-alive" connection option.
937
938NEW:
939
940    A client MAY send additional requests on a persistent connection
941    until it sends or receives a "close" connection option or receives an
942    HTTP/1.0 response without a "keep-alive" connection option.
943
944
945Section 6.3., paragraph 10:
946OLD:
947
948    See Appendix A.1.2 for more information on backward compatibility
949    with HTTP/1.0 clients.
950
951NEW:
952
953    See Appendix A.1.2 for more information on backwards compatibility
954    with HTTP/1.0 clients.
955
956
957Section 6.3.2., paragraph 1:
958OLD:
959
960    A client that supports persistent connections MAY "pipeline" its
961    requests (i.e., send multiple requests without waiting for each
962    response).  A server MAY process a sequence of pipelined requests in
963    parallel if they all have safe methods (Section 4.2.1 of [RFC7231]),
964    but MUST send the corresponding responses in the same order that the
965    requests were received.
966
967NEW:
968
969    A client that supports persistent connections MAY "pipeline" its
970    requests (i.e., send multiple requests without waiting for each
971    response).  A server MAY process a sequence of pipelined requests in
972    parallel if they all have safe methods (Section 4.2.1 of [RFC7231]),
973    but it MUST send the corresponding responses in the same order that
974    the requests were received.
975
976
977Section 6.5., paragraph 4:
978OLD:
979
980    A server SHOULD sustain persistent connections, when possible, and
981    allow the underlying transport's flow control mechanisms to resolve
982    temporary overloads, rather than terminate connections with the
983    expectation that clients will retry.  The latter technique can
984    exacerbate network congestion.
985
986NEW:
987
988    A server SHOULD sustain persistent connections, when possible, and
989    allow the underlying transport's flow-control mechanisms to resolve
990    temporary overloads, rather than terminate connections with the
991    expectation that clients will retry.  The latter technique can
992    exacerbate network congestion.
993
994
995Section 6.5., paragraph 6:
996OLD:
997
998 6.6.  Tear-down
999
1000NEW:
1001
1002 6.6.  Teardown
1003
1004
1005Section 6.5., paragraph 8:
1006OLD:
1007
1008    A client that sends a close connection option MUST NOT send further
1009    requests on that connection (after the one containing close) and MUST
1010    close the connection after reading the final response message
1011    corresponding to this request.
1012
1013NEW:
1014
1015    A client that sends a "close" connection option MUST NOT send further
1016    requests on that connection (after the one containing close) and MUST
1017    close the connection after reading the final response message
1018    corresponding to this request.
1019
1020
1021Section 6.5., paragraph 9:
1022OLD:
1023
1024    A server that receives a close connection option MUST initiate a
1025    close of the connection (see below) after it sends the final response
1026    to the request that contained close.  The server SHOULD send a close
1027    connection option in its final response on that connection.  The
1028    server MUST NOT process any further requests received on that
1029    connection.
1030
1031NEW:
1032
1033    A server that receives a "close" connection option MUST initiate a
1034    close of the connection (see below) after it sends the final response
1035    to the request that contained close.  The server SHOULD send a close
1036    connection option in its final response on that connection.  The
1037    server MUST NOT process any further requests received on that
1038    connection.
1039
1040
1041Section 6.5., paragraph 10:
1042OLD:
1043
1044    A server that sends a close connection option MUST initiate a close
1045    of the connection (see below) after it sends the response containing
1046    close.  The server MUST NOT process any further requests received on
1047    that connection.
1048
1049NEW:
1050
1051    A server that sends a "close" connection option MUST initiate a close
1052    of the connection (see below) after it sends the response containing
1053    close.  The server MUST NOT process any further requests received on
1054    that connection.
1055
1056
1057Section 6.5., paragraph 11:
1058OLD:
1059
1060    A client that receives a close connection option MUST cease sending
1061    requests on that connection and close the connection after reading
1062    the response message containing the close; if additional pipelined
1063    requests had been sent on the connection, the client SHOULD NOT
1064    assume that they will be processed by the server.
1065
1066NEW:
1067
1068    A client that receives a "close" connection option MUST cease sending
1069    requests on that connection and close the connection after reading
1070    the response message containing the close; if additional pipelined
1071    requests had been sent on the connection, the client SHOULD NOT
1072    assume that they will be processed by the server.
1073
1074
1075Section 6.5., paragraph 12:
1076OLD:
1077
1078    If a server performs an immediate close of a TCP connection, there is
1079    a significant risk that the client will not be able to read the last
1080    HTTP response.  If the server receives additional data from the
1081    client on a fully-closed connection, such as another request that was
1082    sent by the client before receiving the server's response, the
1083    server's TCP stack will send a reset packet to the client;
1084    unfortunately, the reset packet might erase the client's
1085    unacknowledged input buffers before they can be read and interpreted
1086    by the client's HTTP parser.
1087
1088NEW:
1089
1090    If a server performs an immediate close of a TCP connection, there is
1091    a significant risk that the client will not be able to read the last
1092    HTTP response.  If the server receives additional data from the
1093    client on a fully closed connection, such as another request that was
1094    sent by the client before receiving the server's response, the
1095    server's TCP stack will send a reset packet to the client;
1096    unfortunately, the reset packet might erase the client's
1097    unacknowledged input buffers before they can be read and interpreted
1098    by the client's HTTP parser.
1099
1100
1101Section 6.7., paragraph 9:
1102OLD:
1103
1104    The capabilities and nature of the application-level communication
1105    after the protocol change is entirely dependent upon the new
1106    protocol(s) chosen.  However, immediately after sending the 101
1107    response, the server is expected to continue responding to the
1108    original request as if it had received its equivalent within the new
1109    protocol (i.e., the server still has an outstanding request to
1110    satisfy after the protocol has been changed, and is expected to do so
1111    without requiring the request to be repeated).
1112
1113NEW:
1114
1115    The capabilities and nature of the application-level communication
1116    after the protocol change is entirely dependent upon the new
1117    protocol(s) chosen.  However, immediately after sending the 101
1118    (Switching Protocols) response, the server is expected to continue
1119    responding to the original request as if it had received its
1120    equivalent within the new protocol (i.e., the server still has an
1121    outstanding request to satisfy after the protocol has been changed,
1122    and is expected to do so without requiring the request to be
1123    repeated).
1124
1125
1126Section 101, paragraph 5:
1127OLD:
1128
1129    A client cannot begin using an upgraded protocol on the connection
1130    until it has completely sent the request message (i.e., the client
1131    can't change the protocol it is sending in the middle of a message).
1132    If a server receives both Upgrade and an Expect header field with the
1133    "100-continue" expectation (Section 5.1.1 of [RFC7231]), the server
1134    MUST send a 100 (Continue) response before sending a 101 (Switching
1135    Protocols) response.
1136
1137NEW:
1138
1139    A client cannot begin using an upgraded protocol on the connection
1140    until it has completely sent the request message (i.e., the client
1141    can't change the protocol it is sending in the middle of a message).
1142    If a server receives both an Upgrade and an Expect header field with
1143    the "100-continue" expectation (Section 5.1.1 of [RFC7231]), the
1144    server MUST send a 100 (Continue) response before sending a 101
1145    (Switching Protocols) response.
1146
1147
1148Section 7., paragraph 14:
1149OLD:
1150
1151    Then the following are valid values for example-list (not including
1152    the double quotes, which are present for delimitation only):
1153
1154NEW:
1155
1156    Then, the following are valid values for example-list (not including
1157    the double quotes, which are present for delimitation only):
1158
1159
1160Section 8.1., paragraph 1:
1161OLD:
1162
1163    HTTP header fields are registered within the Message Header Field
1164    Registry maintained at
1165    <http://www.iana.org/assignments/message-headers/>.
1166
1167NEW:
1168
1169    HTTP header fields are registered within the "Message Header" field
1170    registry maintained at
1171    <http://www.iana.org/assignments/message-headers/>.
1172
1173
1174Section 8.1., paragraph 2:
1175OLD:
1176
1177    This document defines the following HTTP header fields, so their
1178    associated registry entries shall be updated according to the
1179    permanent registrations below (see [BCP90]):
1180
1181NEW:
1182
1183    This document defines the following HTTP header fields, so the
1184    "Permanent Message Header Field Names" registry has been updated
1185    accordingly (see [BCP90]).
1186
1187
1188Section 8.1., paragraph 4:
1189OLD:
1190
1191    Furthermore, the header field-name "Close" shall be registered as
1192    "reserved", since using that name as an HTTP header field might
1193    conflict with the "close" connection option of the "Connection"
1194    header field (Section 6.1).
1195
1196NEW:
1197
1198    Furthermore, the header field-name "Close" has been registered as
1199    "reserved", since using that name as an HTTP header field might
1200    conflict with the "close" connection option of the "Connection"
1201    header field (Section 6.1).
1202
1203
1204Section 8.2., paragraph 2:
1205OLD:
1206
1207    This document defines the following URI schemes, so their associated
1208    registry entries shall be updated according to the permanent
1209    registrations below:
1210
1211NEW:
1212
1213    This document defines the following URI schemes, so the "Permanent
1214    URI Schemes" registry has been updated accordingly.
1215
1216
1217Section 8.3., paragraph 2:
1218OLD:
1219
1220    This document serves as the specification for the Internet media
1221    types "message/http" and "application/http".  The following is to be
1222    registered with IANA.
1223
1224NEW:
1225
1226    This document serves as the specification for the Internet media
1227    types "message/http" and "application/http".  The following has been
1228    registered with IANA.
1229
1230
1231Section 8.3.1., paragraph 18:
1232OLD:
1233
1234    Person and email address to contact for further information:  See
1235       Authors' Addresses Section.
1236
1237NEW:
1238
1239    Person and email address to contact for further information:
1240       See Authors' Addresses  Section.
1241
1242
1243Section 8.3.2., paragraph 8:
1244OLD:
1245
1246    Encoding considerations:  HTTP messages enclosed by this type are in
1247       "binary" format; use of an appropriate Content-Transfer-Encoding
1248       is required when transmitted via E-mail.
1249
1250NEW:
1251
1252    Encoding considerations:  HTTP messages enclosed by this type are in
1253       "binary" format; use of an appropriate Content-Transfer-Encoding
1254       is required when transmitted via email.
1255
1256
1257Section 8.3.2., paragraph 19:
1258OLD:
1259
1260    Person and email address to contact for further information:  See
1261       Authors' Addresses Section.
1262
1263NEW:
1264
1265    Person and email address to contact for further information:
1266       See Authors' Addresses Section.
1267
1268
1269Section 8.4., paragraph 1:
1270OLD:
1271
1272    The HTTP Transfer Coding Registry defines the name space for transfer
1273    coding names.  It is maintained at
1274    <http://www.iana.org/assignments/http-parameters>.
1275
1276NEW:
1277
1278    The "HTTP Transfer Coding" registry defines the namespace for
1279    transfer coding names.  It is maintained at
1280    <http://www.iana.org/assignments/http-parameters>.
1281
1282
1283Section 8.4.1., paragraph 5:
1284OLD:
1285
1286    Values to be added to this name space require IETF Review (see
1287    Section 4.1 of [RFC5226]), and MUST conform to the purpose of
1288    transfer coding defined in this specification.
1289
1290NEW:
1291
1292    Values to be added to this namespace require IETF Review (see Section
1293    4.1 of [RFC5226]), and MUST conform to the purpose of transfer coding
1294    defined in this specification.
1295
1296
1297Section 8.4.2., paragraph 1:
1298OLD:
1299
1300    The HTTP Transfer Coding Registry shall be updated with the
1301    registrations below:
1302
1303NEW:
1304
1305    The "HTTP Transfer Coding Registry" has been updated with the
1306    registrations below:
1307
1308
1309Section 8.5., paragraph 1:
1310OLD:
1311
1312    IANA maintains the registry of HTTP Content Codings at
1313    <http://www.iana.org/assignments/http-parameters>.
1314
1315NEW:
1316
1317    IANA maintains the "HTTP Content Coding Registry" at
1318    <http://www.iana.org/assignments/http-parameters>.
1319
1320
1321Section 8.5., paragraph 2:
1322OLD:
1323
1324    The HTTP Content Codings Registry shall be updated with the
1325    registrations below:
1326
1327NEW:
1328
1329    The "HTTP Content Codings Registry" has been updated with the
1330    registrations below:
1331
1332
1333Section 8.6., paragraph 1:
1334OLD:
1335
1336    The HTTP Upgrade Token Registry defines the name space for protocol-
1337    name tokens used to identify protocols in the Upgrade header field.
1338    The registry is maintained at
1339    <http://www.iana.org/assignments/http-upgrade-tokens>.
1340
1341NEW:
1342
1343    The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
1344    defines the namespace for protocol-name tokens used to identify
1345    protocols in the Upgrade header field.  The registry is maintained at
1346    <http://www.iana.org/assignments/http-upgrade-tokens>.
1347
1348
1349Section 8.6.2., paragraph 1:
1350OLD:
1351
1352    The "HTTP" entry in the HTTP Upgrade Token Registry shall be updated
1353    with the registration below:
1354
1355NEW:
1356
1357    The "HTTP" entry in the "HTTP Upgrade Token" registry shall be
1358    updated with the registration below:
1359
1360
1361Section 9.1., paragraph 3:
1362OLD:
1363
1364    When a registered name is used in the authority component, the "http"
1365    URI scheme (Section 2.7.1) relies on the user's local name resolution
1366    service to determine where it can find authoritative responses.  This
1367    means that any attack on a user's network host table, cached names,
1368    or name resolution libraries becomes an avenue for attack on
1369    establishing authority.  Likewise, the user's choice of server for
1370    Domain Name Service (DNS), and the hierarchy of servers from which it
1371    obtains resolution results, could impact the authenticity of address
1372    mappings; DNSSEC ([RFC4033]) is one way to improve authenticity.
1373
1374NEW:
1375
1376    When a registered name is used in the authority component, the "http"
1377    URI scheme (Section 2.7.1) relies on the user's local name resolution
1378    service to determine where it can find authoritative responses.  This
1379    means that any attack on a user's network host table, cached names,
1380    or name resolution libraries becomes an avenue for attack on
1381    establishing authority.  Likewise, the user's choice of server for
1382    Domain Name Service (DNS), and the hierarchy of servers from which it
1383    obtains resolution results, could impact the authenticity of address
1384    mappings; DNS Security Extensions (DNSSEC) ([RFC4033]) is one way to
1385    improve authenticity.
1386
1387
1388Section 9.2., paragraph 1:
1389OLD:
1390
1391    By their very nature, HTTP intermediaries are men-in-the-middle, and
1392    thus represent an opportunity for man-in-the-middle attacks.
1393    Compromise of the systems on which the intermediaries run can result
1394    in serious security and privacy problems.  Intermediaries might have
1395    access to security-related information, personal information about
1396    individual users and organizations, and proprietary information
1397    belonging to users and content providers.  A compromised
1398    intermediary, or an intermediary implemented or configured without
1399    regard to security and privacy considerations, might be used in the
1400    commission of a wide range of potential attacks.
1401
1402NEW:
1403
1404    By their very nature, HTTP intermediaries are men in the middle and,
1405    thus, represent an opportunity for man-in-the-middle attacks.
1406    Compromise of the systems on which the intermediaries run can result
1407    in serious security and privacy problems.  Intermediaries might have
1408    access to security-related information, personal information about
1409    individual users and organizations, and proprietary information
1410    belonging to users and content providers.  A compromised
1411    intermediary, or an intermediary implemented or configured without
1412    regard to security and privacy considerations, might be used in the
1413    commission of a wide range of potential attacks.
1414
1415
1416Section 9.6., paragraph 2:
1417OLD:
1418
1419    User agents are encouraged to implement configurable means for
1420    detecting and reporting failures of message integrity such that those
1421    means can be enabled within environments for which integrity is
1422    necessary.  For example, a browser being used to view medical history
1423    or drug interaction information needs to indicate to the user when
1424    such information is detected by the protocol to be incomplete,
1425    expired, or corrupted during transfer.  Such mechanisms might be
1426    selectively enabled via user agent extensions or the presence of
1427    message integrity metadata in a response.  At a minimum, user agents
1428    ought to provide some indication that allows a user to distinguish
1429    between a complete and incomplete response message (Section 3.4) when
1430    such verification is desired.
1431
1432NEW:
1433
1434    User agents are encouraged to implement configurable means for
1435    detecting and reporting failures of message integrity such that those
1436    means can be enabled within environments for which integrity is
1437    necessary.  For example, a browser being used to view medical history
1438    or drug interaction information needs to indicate to the user when
1439    such information is detected by the protocol to be incomplete,
1440    expired, or corrupted during transfer.  Such mechanisms might be
1441    selectively enabled via user-agent extensions or the presence of
1442    message integrity metadata in a response.  At a minimum, user agents
1443    ought to provide some indication that allows a user to distinguish
1444    between a complete and incomplete response message (Section 3.4) when
1445    such verification is desired.
1446
1447
1448Section 9.8., paragraph 2:
1449OLD:
1450
1451    HTTP log information is confidential in nature; its handling is often
1452    constrained by laws and regulations.  Log information needs to be
1453    securely stored and appropriate guidelines followed for its analysis.
1454    Anonymization of personal information within individual entries
1455    helps, but is generally not sufficient to prevent real log traces
1456    from being re-identified based on correlation with other access
1457    characteristics.  As such, access traces that are keyed to a specific
1458    client are unsafe to publish even if the key is pseudonymous.
1459
1460NEW:
1461
1462    HTTP log information is confidential in nature; its handling is often
1463    constrained by laws and regulations.  Log information needs to be
1464    securely stored and appropriate guidelines followed for its analysis.
1465    Anonymization of personal information within individual entries
1466    helps, but it is generally not sufficient to prevent real log traces
1467    from being re-identified based on correlation with other access
1468    characteristics.  As such, access traces that are keyed to a specific
1469    client are unsafe to publish even if the key is pseudonymous.
1470
1471
1472Section 11.1., paragraph 1:
1473OLD:
1474
1475    [RFC0793]     Postel, J., "Transmission Control Protocol", STD 7,
1476                  RFC 793, September 1981.
1477 
1478    [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
1479                  Format Specification version 3.3", RFC 1950, May 1996.
1480
1481NEW:
1482
1483    [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
1484                  Format Specification version 3.3", RFC 1950, May 1996.
1485
1486
1487Section 11.1., paragraph 7:
1488OLD:
1489
1490    [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1491                  Transfer Protocol (HTTP/1.1): Semantics and Content",
1492                  draft-ietf-httpbis-p2-semantics-latest (work in
1493                  progress), May 2014.
1494
1495NEW:
1496
1497    [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1498                  Transfer Protocol (HTTP/1.1): Semantics and Content",
1499                  RFC 7231, May 2014.
1500
1501
1502Section 11.1., paragraph 8:
1503OLD:
1504
1505    [RFC7232]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1506                  Transfer Protocol (HTTP/1.1): Conditional Requests",
1507                  draft-ietf-httpbis-p4-conditional-latest (work in
1508                  progress), May 2014.
1509
1510NEW:
1511
1512    [RFC7232]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1513                  Transfer Protocol (HTTP/1.1): Conditional Requests",
1514                  RFC 7232, May 2014.
1515
1516
1517Section 11.1., paragraph 9:
1518OLD:
1519
1520    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1521                  "Hypertext Transfer Protocol (HTTP/1.1): Range
1522                  Requests", draft-ietf-httpbis-p5-range-latest (work in
1523                  progress), May 2014.
1524
1525NEW:
1526
1527    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1528                  "Hypertext Transfer Protocol (HTTP/1.1): Range
1529                  Requests", RFC 7233, May 2014.
1530
1531
1532Section 11.1., paragraph 10:
1533OLD:
1534
1535    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1536                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1537                  draft-ietf-httpbis-p6-cache-latest (work in progress),
1538                  May 2014.
1539
1540NEW:
1541
1542    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1543                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1544                  RFC 7234, May 2014.
1545
1546
1547Section 11.1., paragraph 11:
1548OLD:
1549
1550    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1551                  Transfer Protocol (HTTP/1.1): Authentication",
1552                  draft-ietf-httpbis-p7-auth-latest (work in progress),
1553                  May 2014.
1554
1555NEW:
1556
1557    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1558                  Transfer Protocol (HTTP/1.1): Authentication",
1559                  RFC 7235, May 2014.
1560 
1561    [RFC793]      Postel, J., "Transmission Control Protocol", STD 7,
1562                  RFC 793, September 1981.
1563
1564
1565Section 11.1., paragraph 13:
1566OLD:
1567
1568    [Welch]       Welch, T., "A Technique for High Performance Data
1569                  Compression", IEEE Computer 17(6), June 1984.
1570
1571NEW:
1572
1573    [Welch]       Welch, T., "A Technique for High-Performance Data
1574                  Compression", IEEE Computer 17(6), June 1984.
1575
1576
1577Appendix A., paragraph 1:
1578OLD:
1579
1580    HTTP has been in use since 1990.  The first version, later referred
1581    to as HTTP/0.9, was a simple protocol for hypertext data transfer
1582    across the Internet, using only a single request method (GET) and no
1583    metadata.  HTTP/1.0, as defined by [RFC1945], added a range of
1584    request methods and MIME-like messaging, allowing for metadata to be
1585    transferred and modifiers placed on the request/response semantics.
1586    However, HTTP/1.0 did not sufficiently take into consideration the
1587    effects of hierarchical proxies, caching, the need for persistent
1588    connections, or name-based virtual hosts.  The proliferation of
1589    incompletely-implemented applications calling themselves "HTTP/1.0"
1590    further necessitated a protocol version change in order for two
1591    communicating applications to determine each other's true
1592    capabilities.
1593
1594NEW:
1595
1596    HTTP has been in use since 1990.  The first version, later referred
1597    to as HTTP/0.9, was a simple protocol for hypertext data transfer
1598    across the Internet, using only a single request method (GET) and no
1599    metadata.  HTTP/1.0, as defined by [RFC1945], added a range of
1600    request methods and MIME-like messaging, allowing for metadata to be
1601    transferred and modifiers placed on the request/response semantics.
1602    However, HTTP/1.0 did not sufficiently take into consideration the
1603    effects of hierarchical proxies, caching, the need for persistent
1604    connections, or name-based virtual hosts.  The proliferation of
1605    incompletely implemented applications calling themselves "HTTP/1.0"
1606    further necessitated a protocol version change in order for two
1607    communicating applications to determine each other's true
1608    capabilities.
1609
1610
1611Appendix A., paragraph 2:
1612OLD:
1613
1614    HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
1615    requirements that enable reliable implementations, adding only those
1616    features that can either be safely ignored by an HTTP/1.0 recipient
1617    or only sent when communicating with a party advertising conformance
1618    with HTTP/1.1.
1619
1620NEW:
1621
1622    HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
1623    requirements that enable reliable implementations, adding only those
1624    features that can either be safely ignored by an HTTP/1.0 recipient
1625    or only be sent when communicating with a party advertising
1626    conformance with HTTP/1.1.
1627
1628
1629Appendix A., paragraph 7:
1630OLD:
1631
1632 A.1.1.  Multi-homed Web Servers
1633
1634NEW:
1635
1636 A.1.1.  Multihomed Web Servers
1637
1638
1639Section 19.7.1, paragraph 8:
1640OLD:
1641
1642    HTTP's approach to error handling has been explained.  (Section 2.5)
1643
1644NEW:
1645
1646    HTTP's approach to error handling has been explained (Section 2.5).
1647
1648
1649Section 19.7.1, paragraph 9:
1650OLD:
1651
1652    The HTTP-version ABNF production has been clarified to be case-
1653    sensitive.  Additionally, version numbers has been restricted to
1654    single digits, due to the fact that implementations are known to
1655    handle multi-digit version numbers incorrectly.  (Section 2.6)
1656
1657NEW:
1658
1659    The HTTP-version ABNF production has been clarified to be case
1660    sensitive.  Additionally, version numbers have been restricted to
1661    single digits, due to the fact that implementations are known to
1662    handle multi-digit version numbers incorrectly (Section 2.6).
1663
1664
1665Section 19.7.1, paragraph 10:
1666OLD:
1667
1668    Userinfo (i.e., username and password) are now disallowed in HTTP and
1669    HTTPS URIs, because of security issues related to their transmission
1670    on the wire.  (Section 2.7.1)
1671
1672NEW:
1673
1674    Userinfo (i.e., username and password) are now disallowed in HTTP and
1675    HTTPS URIs, because of security issues related to their transmission
1676    on the wire (Section 2.7.1).
1677
1678
1679Section 19.7.1, paragraph 11:
1680OLD:
1681
1682    The HTTPS URI scheme is now defined by this specification;
1683    previously, it was done in Section 2.4 of [RFC2818].  Furthermore, it
1684    implies end-to-end security.  (Section 2.7.2)
1685
1686NEW:
1687
1688    The HTTPS URI scheme is now defined by this specification;
1689    previously, it was defined in Section 2.4 of [RFC2818].  Furthermore,
1690    it implies end-to-end security (Section 2.7.2).
1691
1692
1693Section 19.7.1, paragraph 12:
1694OLD:
1695
1696    HTTP messages can be (and often are) buffered by implementations;
1697    despite it sometimes being available as a stream, HTTP is
1698    fundamentally a message-oriented protocol.  Minimum supported sizes
1699    for various protocol elements have been suggested, to improve
1700    interoperability.  (Section 3)
1701
1702NEW:
1703
1704    HTTP messages can be (and often are) buffered by implementations;
1705    despite it sometimes being available as a stream, HTTP is
1706    fundamentally a message-oriented protocol.  Minimum supported sizes
1707    for various protocol elements have been suggested, to improve
1708    interoperability (Section 3).
1709
1710
1711Section 19.7.1, paragraph 13:
1712OLD:
1713
1714    Invalid whitespace around field-names is now required to be rejected,
1715    because accepting it represents a security vulnerability.  The ABNF
1716    productions defining header fields now only list the field value.
1717    (Section 3.2)
1718
1719NEW:
1720
1721    Invalid whitespace around field-names is now required to be rejected,
1722    because accepting it represents a security vulnerability.  The ABNF
1723    productions defining header fields now only list the field value
1724    (Section 3.2).
1725
1726
1727Section 19.7.1, paragraph 14:
1728OLD:
1729
1730    Rules about implicit linear whitespace between certain grammar
1731    productions have been removed; now whitespace is only allowed where
1732    specifically defined in the ABNF.  (Section 3.2.3)
1733
1734NEW:
1735
1736    Rules about implicit linear whitespace between certain grammar
1737    productions have been removed; now whitespace is only allowed where
1738    specifically defined in the ABNF (Section 3.2.3).
1739
1740
1741Section 19.7.1, paragraph 15:
1742OLD:
1743
1744    Header fields that span multiple lines ("line folding") are
1745    deprecated.  (Section 3.2.4)
1746    The NUL octet is no longer allowed in comment and quoted-string text,
1747    and handling of backslash-escaping in them has been clarified.  The
1748    quoted-pair rule no longer allows escaping control characters other
1749    than HTAB.  Non-ASCII content in header fields and the reason phrase
1750    has been obsoleted and made opaque (the TEXT rule was removed).
1751    (Section 3.2.6)
1752
1753NEW:
1754
1755    Header fields that span multiple lines ("line folding") are
1756    deprecated (Section 3.2.4).
1757 
1758    The NUL octet is no longer allowed in comment and quoted-string text,
1759    and handling of backslash-escaping in them has been clarified.  The
1760    quoted-pair rule no longer allows escaping control characters other
1761    than HTAB.  Non-US-ASCII content in header fields and the reason
1762    phrase has been obsoleted and made opaque (the TEXT rule was removed)
1763    (Section 3.2.6).
1764
1765
1766Section 19.7.1, paragraph 16:
1767OLD:
1768
1769    Bogus "Content-Length" header fields are now required to be handled
1770    as errors by recipients.  (Section 3.3.2)
1771
1772NEW:
1773
1774    Bogus "Content-Length" header fields are now required to be handled
1775    as errors by recipients (Section 3.3.2).
1776
1777
1778Section 19.7.1, paragraph 17:
1779OLD:
1780
1781    The algorithm for determining the message body length has been
1782    clarified to indicate all of the special cases (e.g., driven by
1783    methods or status codes) that affect it, and that new protocol
1784    elements cannot define such special cases.  CONNECT is a new, special
1785    case in determining message body length. "multipart/byteranges" is no
1786    longer a way of determining message body length detection.
1787    (Section 3.3.3)
1788
1789NEW:
1790
1791    The algorithm for determining the message body length has been
1792    clarified to indicate all of the special cases (e.g., driven by
1793    methods or status codes) that affect it, and that new protocol
1794    elements cannot define such special cases.  CONNECT is a new, special
1795    case in determining message body length. "multipart/byteranges" is no
1796    longer a way of determining message body length detection
1797    (Section 3.3.3).
1798
1799
1800Section 19.7.1, paragraph 18:
1801OLD:
1802
1803    The "identity" transfer coding token has been removed.  (Sections 3.3
1804    and 4)
1805
1806NEW:
1807
1808    The "identity" transfer coding token has been removed (Sections 3.3
1809    and 4).
1810
1811
1812Section 19.7.1, paragraph 19:
1813OLD:
1814
1815    Chunk length does not include the count of the octets in the chunk
1816    header and trailer.  Line folding in chunk extensions is disallowed.
1817    (Section 4.1)
1818
1819NEW:
1820
1821    Chunk length does not include the count of the octets in the chunk
1822    header and trailer.  Line folding in chunk extensions is disallowed
1823    (Section 4.1).
1824
1825
1826Section 19.7.1, paragraph 20:
1827OLD:
1828
1829    The meaning of the "deflate" content coding has been clarified.
1830    (Section 4.2.2)
1831
1832NEW:
1833
1834    The meaning of the "deflate" content coding has been clarified
1835    (Section 4.2.2).
1836
1837
1838Section 19.7.1, paragraph 21:
1839OLD:
1840
1841    The segment + query components of RFC 3986 have been used to define
1842    the request-target, instead of abs_path from RFC 1808.  The asterisk-
1843    form of the request-target is only allowed with the OPTIONS method.
1844    (Section 5.3)
1845
1846NEW:
1847
1848    The segment + query components of RFC 3986 have been used to define
1849    the request-target, instead of abs_path from RFC 1808.  The asterisk-
1850    form of the request-target is only allowed with the OPTIONS method
1851    (Section 5.3).
1852
1853
1854Section 19.7.1, paragraph 22:
1855OLD:
1856
1857    The term "Effective Request URI" has been introduced.  (Section 5.5)
1858
1859NEW:
1860
1861    The term "Effective Request URI" has been introduced (Section 5.5).
1862
1863
1864Section 19.7.1, paragraph 23:
1865OLD:
1866
1867    Gateways do not need to generate Via header fields anymore.
1868    (Section 5.7.1)
1869
1870NEW:
1871
1872    Gateways do not need to generate Via header fields anymore
1873    (Section 5.7.1).
1874
1875
1876Section 19.7.1, paragraph 24:
1877OLD:
1878
1879    Exactly when "close" connection options have to be sent has been
1880    clarified.  Also, "hop-by-hop" header fields are required to appear
1881    in the Connection header field; just because they're defined as hop-
1882    by-hop in this specification doesn't exempt them.  (Section 6.1)
1883
1884NEW:
1885
1886    Exactly when "close" connection options have to be sent has been
1887    clarified.  Also, "hop-by-hop" header fields are required to appear
1888    in the Connection header field; just because they're defined as hop-
1889    by-hop in this specification doesn't exempt them (Section 6.1).
1890
1891
1892Section 19.7.1, paragraph 25:
1893OLD:
1894
1895    The limit of two connections per server has been removed.  An
1896    idempotent sequence of requests is no longer required to be retried.
1897    The requirement to retry requests under certain circumstances when
1898    the server prematurely closes the connection has been removed.  Also,
1899    some extraneous requirements about when servers are allowed to close
1900    connections prematurely have been removed.  (Section 6.3)
1901
1902NEW:
1903
1904    The limit of two connections per server has been removed.  An
1905    idempotent sequence of requests is no longer required to be retried.
1906    The requirement to retry requests under certain circumstances when
1907    the server prematurely closes the connection has been removed.  Also,
1908    some extraneous requirements about when servers are allowed to close
1909    connections prematurely have been removed (Section 6.3).
1910
1911
1912Section 19.7.1, paragraph 26:
1913OLD:
1914
1915    The semantics of the Upgrade header field is now defined in responses
1916    other than 101 (this was incorporated from [RFC2817]).  Furthermore,
1917    the ordering in the field value is now significant.  (Section 6.7)
1918
1919NEW:
1920
1921    The semantics of the Upgrade header field is now defined in responses
1922    other than 101 (this was incorporated from [RFC2817]).  Furthermore,
1923    the ordering in the field value is now significant (Section 6.7).
1924
1925
1926Section 19.7.1, paragraph 27:
1927OLD:
1928
1929    Empty list elements in list productions (e.g., a list header field
1930    containing ", ,") have been deprecated.  (Section 7)
1931
1932NEW:
1933
1934    Empty list elements in list productions (e.g., a list header field
1935    containing ", ,") have been deprecated (Section 7).
1936
1937
1938Section 19.7.1, paragraph 28:
1939OLD:
1940
1941    Registration of Transfer Codings now requires IETF Review
1942    (Section 8.4)
1943
1944NEW:
1945
1946    Registration of Transfer Codings now requires IETF Review
1947    (Section 8.4).
1948
1949
1950Section 19.7.1, paragraph 29:
1951OLD:
1952
1953    This specification now defines the Upgrade Token Registry, previously
1954    defined in Section 7.2 of [RFC2817].  (Section 8.6)
1955
1956NEW:
1957
1958    This specification now defines the "HTTP Upgrade Tokens" registry,
1959    previously defined in Section 7.2 of [RFC2817] (Section 8.6).
1960
1961
1962Section 19.7.1, paragraph 30:
1963OLD:
1964
1965    The expectation to support HTTP/0.9 requests has been removed.
1966    (Appendix A)
1967
1968NEW:
1969
1970    The expectation to support HTTP/0.9 requests has been removed
1971    (Appendix A).
1972
1973
1974Section 19.7.1, paragraph 31:
1975OLD:
1976
1977    Issues with the Keep-Alive and Proxy-Connection header fields in
1978    requests are pointed out, with use of the latter being discouraged
1979    altogether.  (Appendix A.1.2)
1980
1981NEW:
1982
1983    Issues with the Keep-Alive and Proxy-Connection header fields in
1984    requests are pointed out, with use of the latter being discouraged
1985    altogether (Appendix A.1.2).
1986
1987
1988Appendix B., paragraph 7:
1989OLD:
1990
1991    URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
1992    Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
1993    Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
1994     ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
1995     comment ] ) ] )
1996
1997NEW:
1998
1999    URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
2000    Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
2001 
2002    Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
2003     ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
2004     comment ] ) ] )
2005
2006
2007Appendix B., paragraph 15:
2008OLD:
2009
2010    partial-URI = relative-part [ "?" query ]
2011    path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
2012    port = <port, defined in [RFC3986], Section 3.2.3>
2013    protocol = protocol-name [ "/" protocol-version ]
2014    protocol-name = token
2015    protocol-version = token
2016    pseudonym = token
2017 
2018    qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
2019     / %x5D-7E ; ']'-'~'
2020     / obs-text
2021    query = <query, defined in [RFC3986], Section 3.4>
2022    quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
2023    quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
2024
2025NEW:
2026
2027    partial-URI = relative-part [ "?" query ]
2028    path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
2029    port = <port, defined in [RFC3986], Section 3.2.3>
2030    protocol = protocol-name [ "/" protocol-version ]
2031    protocol-name = token
2032    protocol-version = token
2033    pseudonym = token
2034    qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
2035     / %x5D-7E ; ']'-'~'
2036     / obs-text
2037    query = <query, defined in [RFC3986], Section 3.4>
2038    quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
2039    quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
2040
2041
2042Appendix B., paragraph 24:
2043OLD:
2044
2045    D
2046       deflate (Coding Format)  38
2047       Delimiters  26
2048       downstream  9
2049
2050NEW:
2051
2052    D
2053       deflate (Coding Format)  38
2054       Delimiters  26
2055       downstream  10
2056
2057
2058Appendix B., paragraph 26:
2059OLD:
2060
2061    G
2062       gateway  10
2063       Grammar
2064          absolute-form  41-42
2065          absolute-path  16
2066          absolute-URI  16
2067          ALPHA  6
2068          asterisk-form  41-42
2069          authority  16
2070          authority-form  41-42
2071          BWS  24
2072          chunk  35
2073          chunk-data  35
2074          chunk-ext  35-36
2075          chunk-ext-name  36
2076          chunk-ext-val  36
2077          chunk-size  35
2078          chunked-body  35-36
2079          comment  27
2080          Connection  51
2081          connection-option  51
2082          Content-Length  30
2083          CR  6
2084          CRLF  6
2085          ctext  27
2086          CTL  6
2087          DIGIT  6
2088          DQUOTE  6
2089          field-content  22
2090          field-name  22, 39
2091          field-value  22
2092          field-vchar  22
2093          fragment  16
2094          header-field  22, 36
2095          HEXDIG  6
2096          Host  43
2097          HTAB  6
2098          HTTP-message  19
2099          HTTP-name  13
2100          http-URI  16
2101          HTTP-version  13
2102          https-URI  18
2103          last-chunk  35
2104          LF  6
2105          message-body  27
2106          method  21
2107          obs-fold  22
2108          obs-text  27
2109          OCTET  6
2110          origin-form  41
2111          OWS  24
2112          partial-URI  16
2113          port  16
2114          protocol-name  47
2115          protocol-version  47
2116          pseudonym  47
2117          qdtext  27
2118          query  16
2119          quoted-pair  27
2120          quoted-string  27
2121          rank  38
2122          reason-phrase  22
2123          received-by  47
2124          received-protocol  47
2125          request-line  21
2126          request-target  41
2127          RWS  24
2128          scheme  16
2129          segment  16
2130          SP  6
2131          start-line  20
2132          status-code  22
2133          status-line  22
2134          t-codings  38
2135          t-ranking  38
2136          tchar  27
2137          TE  38
2138          token  27
2139          Trailer  39
2140          trailer-part  35-36
2141          transfer-coding  35
2142          Transfer-Encoding  28
2143          transfer-extension  35
2144          transfer-parameter  35
2145          Upgrade  56
2146          uri-host  16
2147          URI-reference  16
2148          VCHAR  6
2149          Via  47
2150       gzip (Coding Format)  38
2151
2152NEW:
2153
2154    G
2155       gateway  10
2156       Grammar
2157          absolute-form  41-42
2158          absolute-path  16
2159          absolute-URI  16
2160          ALPHA  6
2161          asterisk-form  41-42
2162          authority  16
2163          authority-form  41-42
2164          BWS  24
2165          chunk  35
2166          chunk-data  35
2167          chunk-ext  35-36
2168          chunk-ext-name  36
2169          chunk-ext-val  36
2170          chunk-size  35
2171          chunked-body  35-36
2172          comment  27
2173          Connection  51
2174          connection-option  51
2175          Content-Length  30
2176          CR  6
2177          CRLF  6
2178          ctext  27
2179          CTL  6
2180          DIGIT  6
2181          DQUOTE  6
2182          field-content  22
2183          field-name  22, 39
2184          field-value  22
2185          field-vchar  22
2186          fragment  16
2187          header-field  22, 36
2188          HEXDIG  6
2189          Host  43
2190          HTAB  6
2191          HTTP-message  19
2192          HTTP-name  14
2193          http-URI  16
2194          HTTP-version  14
2195          https-URI  18
2196          last-chunk  35
2197          LF  6
2198          message-body  27
2199          method  21
2200          obs-fold  22
2201          obs-text  27
2202          OCTET  6
2203          origin-form  41
2204          OWS  24
2205          partial-URI  16
2206          port  16
2207          protocol-name  47
2208          protocol-version  47
2209          pseudonym  47
2210          qdtext  27
2211          query  16
2212          quoted-pair  27
2213          quoted-string  27
2214          rank  38
2215          reason-phrase  22
2216          received-by  47
2217          received-protocol  47
2218          request-line  21
2219          request-target  41
2220          RWS  24
2221          scheme  16
2222          segment  16
2223          SP  6
2224          start-line  20
2225          status-code  22
2226          status-line  22
2227          t-codings  38
2228          t-ranking  38
2229          tchar  27
2230          TE  38
2231          token  27
2232          Trailer  39
2233          trailer-part  35-36
2234          transfer-coding  35
2235          Transfer-Encoding  28
2236          transfer-extension  35
2237          transfer-parameter  35
2238          Upgrade  56
2239          uri-host  16
2240          URI-reference  16
2241          VCHAR  6
2242          Via  47
2243       gzip (Coding Format)  38
2244
2245
2246Appendix B., paragraph 28:
2247OLD:
2248
2249    I
2250       inbound  9
2251       interception proxy  11
2252       intermediary  9
2253
2254NEW:
2255
2256    I
2257       inbound  10
2258       interception proxy  11
2259       intermediary  9
2260
2261
2262Appendix B., paragraph 31:
2263OLD:
2264
2265    O
2266       origin server  7
2267       origin-form (of request-target)  41
2268       outbound  9
2269
2270NEW:
2271
2272    O
2273       origin server  7
2274       origin-form (of request-target)  41
2275       outbound  10
2276
2277
2278Appendix B., paragraph 36:
2279OLD:
2280
2281    U
2282       Upgrade header field  56
2283       upstream  9
2284       URI scheme
2285          http  16
2286          https  18
2287       user agent  7
2288
2289NEW:
2290
2291    U
2292       Upgrade header field  56
2293       upstream  10
2294       URI scheme
2295          http  16
2296          https  18
2297       user agent  7
2298
2299
2300Section 345, paragraph 1:
2301OLD:
2302
2303    EMail: fielding@gbiv.com
2304    URI:   http://roy.gbiv.com/
2305 
2306    Julian F. Reschke (editor)
2307    greenbytes GmbH
2308    Hafenweg 16
2309    Muenster, NW  48155
2310    Germany
2311
2312NEW:
2313
2314    EMail: fielding@gbiv.com
2315    URI:   http://roy.gbiv.com/
2316    Julian F. Reschke (editor)
2317    greenbytes GmbH
2318    Hafenweg 16
2319    Muenster, NW  48155
2320    Germany
2321
Note: See TracBrowser for help on using the repository browser.