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

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

whitespace/hyphenation (#553)

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