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

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

min. fixes (reg names, punctuation, etc) (see #553)

File size: 62.2 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 8, 2014
10 Intended status: Standards Track
11 Expires: November 9, 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 9, 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  . . . . . . . . . . . . . . . . . . . . 24
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 . . . . . . . . . . . . . . . . . . . . 29
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 . . . . . . . . . . . . . . . . . . . . . . . 34
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  . . . . . . . . . . . . . . . . . . . 37
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  . . . . . . . . . . . . . . . . . . . . . . . 39
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  . . . . . . . . . . . . . . . . . . . . 41
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  . . . . . . . . . . . . . . . . . . . . . . . . . 46
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  . . . . . . . . . . . . . . . . . . . . . . . 51
167        6.3.1.  Retrying Requests  . . . . . . . . . . . . . . . . . . 52
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  . . . . . . . . . . . . . . . . . . . . . 59
176      8.1.  Header Field Registration  . . . . . . . . . . . . . . . . 59
177      8.2.  URI Scheme Registration  . . . . . . . . . . . . . . . . . 60
178      8.3.  Internet Media Type Registration . . . . . . . . . . . . . 60
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 . . . . . . . . . . . . . . . . . . 64
186        8.6.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 65
187        8.6.2.  Upgrade Token Registration . . . . . . . . . . . . . . 65
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  . . . . . . . . . . . 67
192      9.4.  Response Splitting . . . . . . . . . . . . . . . . . . . . 68
193      9.5.  Request Smuggling  . . . . . . . . . . . . . . . . . . . . 69
194      9.6.  Message Integrity  . . . . . . . . . . . . . . . . . . . . 69
195      9.7.  Message Confidentiality  . . . . . . . . . . . . . . . . . 69
196      9.8.  Privacy of Server Log Information  . . . . . . . . . . . . 70
197    10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 70
198    11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
199      11.1. Normative References . . . . . . . . . . . . . . . . . . . 72
200      11.2. Informative References . . . . . . . . . . . . . . . . . . 73
201    Appendix A.  HTTP Version History  . . . . . . . . . . . . . . . . 75
202      A.1.  Changes from HTTP/1.0  . . . . . . . . . . . . . . . . . . 76
203        A.1.1.  Multi-homed Web Servers  . . . . . . . . . . . . . . . 76
204        A.1.2.  Keep-Alive Connections . . . . . . . . . . . . . . . . 77
205        A.1.3.  Introduction of Transfer-Encoding  . . . . . . . . . . 77
206      A.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 77
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.3., paragraph 7:
333OLD:
334
335    All HTTP requirements applicable to an origin server also apply to
336    the outbound communication of a gateway.  A gateway communicates with
337    inbound servers using any protocol that it desires, including private
338    extensions to HTTP that are outside the scope of this specification.
339    However, an HTTP-to-HTTP gateway that wishes to interoperate with
340    third-party HTTP servers ought to conform to user agent requirements
341    on the gateway's inbound connection.
342
343NEW:
344
345    All HTTP requirements applicable to an origin server also apply to
346    the outbound communication of a gateway.  A gateway communicates with
347    inbound servers using any protocol that it desires, including private
348    extensions to HTTP that are outside the scope of this specification.
349    However, an HTTP-to-HTTP gateway that wishes to interoperate with
350    third-party HTTP servers ought to conform to user-agent requirements
351    on the gateway's inbound connection.
352
353
354Section 2.6., paragraph 2:
355OLD:
356
357    The version of an HTTP message is indicated by an HTTP-version field
358    in the first line of the message.  HTTP-version is case-sensitive.
359
360NEW:
361
362    The version of an HTTP message is indicated by an HTTP-version field
363    in the first line of the message.  HTTP-version is case sensitive.
364
365
366Section 2.6., paragraph 3:
367OLD:
368
369      HTTP-version  = HTTP-name "/" DIGIT "." DIGIT
370      HTTP-name     = %x48.54.54.50 ; "HTTP", case-sensitive
371
372NEW:
373
374      HTTP-version  = HTTP-name "/" DIGIT "." DIGIT
375      HTTP-name     = %x48.54.54.50 ; "HTTP", case sensitive
376
377
378Section 2.6., paragraph 7:
379OLD:
380
381    New header fields can be introduced without changing the protocol
382    version if their defined semantics allow them to be safely ignored by
383    recipients that do not recognize them.  Header field extensibility is
384    discussed in Section 3.2.1.
385
386NEW:
387
388    New header fields can be introduced without changing the protocol
389    version if their defined semantics allow them to be safely ignored by
390    recipients that do not recognize them.  Header-field extensibility is
391    discussed in Section 3.2.1.
392
393
394Section 2.6., paragraph 14:
395OLD:
396
397    When an HTTP message is received with a major version number that the
398    recipient implements, but a higher minor version number than what the
399    recipient implements, the recipient SHOULD process the message as if
400    it were in the highest minor version within that major version to
401    which the recipient is conformant.  A recipient can assume that a
402    message with a higher minor version, when sent to a recipient that
403    has not yet indicated support for that higher version, is
404    sufficiently backwards-compatible to be safely processed by any
405    implementation of the same major version.
406
407NEW:
408
409    When an HTTP message is received with a major version number that the
410    recipient implements, but a higher minor version number than what the
411    recipient implements, the recipient SHOULD process the message as if
412    it were in the highest minor version within that major version to
413    which the recipient is conformant.  A recipient can assume that a
414    message with a higher minor version, when sent to a recipient that
415    has not yet indicated support for that higher version, is
416    sufficiently backwards compatible to be safely processed by any
417    implementation of the same major version.
418
419
420Section 2.7.1., paragraph 1:
421OLD:
422
423    The "http" URI scheme is hereby defined for the purpose of minting
424    identifiers according to their association with the hierarchical
425    namespace governed by a potential HTTP origin server listening for
426    TCP ([RFC0793]) connections on a given port.
427
428NEW:
429
430    The "http" URI scheme is hereby defined for the purpose of minting
431    identifiers according to their association with the hierarchical
432    namespace governed by a potential HTTP origin server listening for
433    TCP ([RFC793]) connections on a given port.
434
435
436Section 2.1, paragraph 0:
437OLD:
438
439    If the port is equal to the default port for a scheme, the normal
440    form is to omit the port subcomponent.  When not being used in
441    absolute form as the request target of an OPTIONS request, an empty
442    path component is equivalent to an absolute path of "/", so the
443    normal form is to provide a path of "/" instead.  The scheme and host
444    are case-insensitive and normally provided in lowercase; all other
445    components are compared in a case-sensitive manner.  Characters other
446    than those in the "reserved" set are equivalent to their percent-
447    encoded octets: the normal form is to not encode them (see Sections
448    2.1 and 2.2 of [RFC3986]).
449
450NEW:
451
452    If the port is equal to the default port for a scheme, the normal
453    form is to omit the port subcomponent.  When not being used in
454    absolute form as the request target of an OPTIONS request, an empty
455    path component is equivalent to an absolute path of "/", so the
456    normal form is to provide a path of "/" instead.  The scheme and host
457    are case insensitive and normally provided in lowercase; all other
458    components are compared in a case-sensitive manner.  Characters other
459    than those in the "reserved" set are equivalent to their percent-
460    encoded octets: the normal form is to not encode them (see Sections
461    2.1 and 2.2 of [RFC3986]).
462
463
464Section 3.1., paragraph 2:
465OLD:
466
467    In theory, a client could receive requests and a server could receive
468    responses, distinguishing them by their different start-line formats,
469    but, in practice, servers are implemented to only expect a request (a
470    response is interpreted as an unknown or invalid request method) and
471    clients are implemented to only expect a response.
472
473NEW:
474
475    In theory, a client could receive requests and a server could receive
476    responses, distinguishing them by their different start-line formats,
477    but, in practice, servers are implemented only to expect a request (a
478    response is interpreted as an unknown or invalid request method) and
479    clients are implemented to only expect a response.
480
481
482Section 3.1.1., paragraph 1:
483OLD:
484
485    A request-line begins with a method token, followed by a single space
486    (SP), the request-target, another single space (SP), the protocol
487    version, and ends with CRLF.
488
489NEW:
490
491    A request-line begins with a method token and is followed by a single
492    space (SP), the request-target, another single space (SP), the
493    protocol version, and ends with CRLF.
494
495
496Section 3.1.1., paragraph 3:
497OLD:
498
499    The method token indicates the request method to be performed on the
500    target resource.  The request method is case-sensitive.
501
502NEW:
503
504    The method token indicates the request method to be performed on the
505    target resource.  The request method is case sensitive.
506
507
508Section 3.1.2., paragraph 1:
509OLD:
510
511    The first line of a response message is the status-line, consisting
512    of the protocol version, a space (SP), the status code, another
513    space, a possibly empty textual phrase describing the status code,
514    and ending with CRLF.
515
516NEW:
517
518    The first line of a response message is the status-line, consisting
519    of the protocol version, a space (SP), the status code, another space
520    (SP), a possibly empty textual phrase describing the status code,
521    and, finally, CRLF.
522
523
524Section 3.2.1., paragraph 4:
525OLD:
526
527    All defined header fields ought to be registered with IANA in the
528    "Message Headers" registry, as described in Section 8.3 of [RFC7231].
529
530NEW:
531
532    All defined header fields ought to be registered with IANA in the
533    "Message Headers" field registry, as described in Section 8.3 of
534    [RFC7231].
535
536
537Section 3.2.2., paragraph 4:
538OLD:
539
540       Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
541       appears multiple times in a response message and does not use the
542       list syntax, violating the above requirements on multiple header
543       fields with the same name.  Since it cannot be combined into a
544       single field-value, recipients ought to handle "Set-Cookie" as a
545       special case while processing header fields.  (See Appendix A.2.3
546       of [Kri2001] for details.)
547
548NEW:
549
550       Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
551       appears multiple times in a response message and does not use the
552       list syntax, violating the above requirements on multiple header
553       fields with the same name.  Since it cannot be combined into a
554       single field-value, recipients ought to handle Set-Cookie as a
555       special case while processing header fields.  (See Appendix A.2.3
556       of [Kri2001] for details.)
557
558
559Section 3.2.4., paragraph 1:
560OLD:
561
562    Messages are parsed using a generic algorithm, independent of the
563    individual header field names.  The contents within a given field
564    value are not parsed until a later stage of message interpretation
565    (usually after the message's entire header section has been
566    processed).  Consequently, this specification does not use ABNF rules
567    to define each "Field-Name: Field Value" pair, as was done in
568    previous editions.  Instead, this specification uses ABNF rules that
569    are named according to each registered field name, wherein the rule
570    defines the valid grammar for that field's corresponding field values
571    (i.e., after the field-value has been extracted from the header
572    section by a generic field parser).
573
574NEW:
575
576    Messages are parsed using a generic algorithm, independent of the
577    individual header field names.  The contents within a given field
578    value are not parsed until a later stage of message interpretation
579    (usually after the message's entire header section has been
580    processed).  Consequently, this specification does not use ABNF rules
581    to define each "field-name: field-value" pair, as was done in
582    previous editions.  Instead, this specification uses ABNF rules that
583    are named according to each registered field name, wherein the rule
584    defines the valid grammar for that field's corresponding field values
585    (i.e., after the field-value has been extracted from the header
586    section by a generic field parser).
587
588
589Section 3.2.4., paragraph 8:
590OLD:
591
592    Historically, HTTP has allowed field content with text in the
593    ISO-8859-1 charset [ISO-8859-1], supporting other charsets only
594    through use of [RFC2047] encoding.  In practice, most HTTP header
595    field values use only a subset of the US-ASCII charset [USASCII].
596    Newly defined header fields SHOULD limit their field values to
597    US-ASCII octets.  A recipient SHOULD treat other octets in field
598    content (obs-text) as opaque data.
599
600NEW:
601
602    Historically, HTTP has allowed field content with text in the
603    ISO-8859-1 [ISO-8859-1] charset, supporting other charsets only
604    through use of [RFC2047] encoding.  In practice, most HTTP header
605    field values use only a subset of the US-ASCII charset [USASCII].
606    Newly defined header fields SHOULD limit their field values to
607    US-ASCII octets.  A recipient SHOULD treat other octets in field
608    content (obs-text) as opaque data.
609
610
611Section 4., paragraph 5:
612OLD:
613
614    All transfer-coding names are case-insensitive and ought to be
615    registered within the HTTP Transfer Coding registry, as defined in
616    Section 8.4.  They are used in the TE (Section 4.3) and Transfer-
617    Encoding (Section 3.3.1) header fields.
618
619NEW:
620
621    All transfer-coding names are case insensitive and ought to be
622    registered within the "HTTP Transfer Coding" registry, as defined in
623    Section 8.4.  They are used in the TE (Section 4.3) and Transfer-
624    Encoding (Section 3.3.1) header fields.
625
626
627Section 5.3.4., paragraph 3:
628OLD:
629
630    When a client wishes to request OPTIONS for the server as a whole, as
631    opposed to a specific named resource of that server, the client MUST
632    send only "*" (%x2A) as the request-target.  For example,
633 
634      OPTIONS * HTTP/1.1
635
636NEW:
637
638    When a client wishes to request OPTIONS for the server as a whole, as
639    opposed to a specific named resource of that server, the client MUST
640    send only "*" (%x2A) as the request-target.  For example,
641      OPTIONS * HTTP/1.1
642
643
644Section 5.7.2., paragraph 6:
645OLD:
646
647    A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of
648    a message that contains a no-transform cache-control directive
649    (Section 5.2 of [RFC7234]).
650
651NEW:
652
653    A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of
654    a message that contains a no-transform Cache-Control directive
655    (Section 5.2 of [RFC7234]).
656
657
658Section 200, paragraph 0:
659OLD:
660
661    A proxy MAY transform the payload of a message that does not contain
662    a no-transform cache-control directive.  A proxy that transforms a
663    payload MUST add a Warning header field with the warn-code of 214
664    ("Transformation Applied") if one is not already in the message (see
665    Section 5.5 of [RFC7234]).  A proxy that transforms the payload of a
666    200 (OK) response can further inform downstream recipients that a
667    transformation has been applied by changing the response status code
668    to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).
669
670NEW:
671
672    A proxy MAY transform the payload of a message that does not contain
673    a no-transform Cache-Control directive.  A proxy that transforms a
674    payload MUST add a Warning header field with the warn-code of 214
675    ("Transformation Applied") if one is not already in the message (see
676    Section 5.5 of [RFC7234]).  A proxy that transforms the payload of a
677    200 (OK) response can further inform downstream recipients that a
678    transformation has been applied by changing the response status code
679    to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).
680
681
682Section 6.1., paragraph 6:
683OLD:
684
685    Connection options are case-insensitive.
686
687NEW:
688
689    Connection options are case insensitive.
690
691
692Section 6.5., paragraph 6:
693OLD:
694
695 6.6.  Tear-down
696
697NEW:
698
699 6.6.  Teardown
700
701
702Section 6.5., paragraph 8:
703OLD:
704
705    A client that sends a "close" connection option MUST NOT send further
706    requests on that connection (after the one containing "close") and
707    MUST close the connection after reading the final response message
708    corresponding to this request.
709
710NEW:
711
712    A client that sends a "close" connection option MUST NOT send further
713    requests on that connection (after the one containing close) and MUST
714    close the connection after reading the final response message
715    corresponding to this request.
716
717
718Section 6.5., paragraph 9:
719OLD:
720
721    A server that receives a "close" connection option MUST initiate a
722    close of the connection (see below) after it sends the final response
723    to the request that contained "close".  The server SHOULD send a
724    "close" connection option in its final response on that connection.
725    The server MUST NOT process any further requests received on that
726    connection.
727
728NEW:
729
730    A server that receives a "close" connection option MUST initiate a
731    close of the connection (see below) after it sends the final response
732    to the request that contained close.  The server SHOULD send a close
733    connection option in its final response on that connection.  The
734    server MUST NOT process any further requests received on that
735    connection.
736
737
738Section 6.5., paragraph 10:
739OLD:
740
741    A server that sends a "close" connection option MUST initiate a close
742    of the connection (see below) after it sends the response containing
743    "close".  The server MUST NOT process any further requests received
744    on that connection.
745
746NEW:
747
748    A server that sends a "close" connection option MUST initiate a close
749    of the connection (see below) after it sends the response containing
750    close.  The server MUST NOT process any further requests received on
751    that connection.
752
753
754Section 6.5., paragraph 11:
755OLD:
756
757    A client that receives a "close" connection option MUST cease sending
758    requests on that connection and close the connection after reading
759    the response message containing the "close"; if additional pipelined
760    requests had been sent on the connection, the client SHOULD NOT
761    assume that they will be processed by the server.
762
763NEW:
764
765    A client that receives a "close" connection option MUST cease sending
766    requests on that connection and close the connection after reading
767    the response message containing the close; if additional pipelined
768    requests had been sent on the connection, the client SHOULD NOT
769    assume that they will be processed by the server.
770
771
772Section 7., paragraph 14:
773OLD:
774
775    Then the following are valid values for example-list (not including
776    the double quotes, which are present for delimitation only):
777
778NEW:
779
780    Then, the following are valid values for example-list (not including
781    the double quotes, which are present for delimitation only):
782
783
784Section 8.1., paragraph 1:
785OLD:
786
787    HTTP header fields are registered within the "Message Headers"
788    registry maintained at
789    <http://www.iana.org/assignments/message-headers/>.
790
791NEW:
792
793    HTTP header fields are registered within the "Message Header" field
794    registry maintained at
795    <http://www.iana.org/assignments/message-headers/>.
796
797
798Section 8.3.1., paragraph 10:
799OLD:
800
801    Interoperability considerations:  N/A
802 
803    Published specification:  This specification (see Section 8.3.1).
804
805NEW:
806
807    Interoperability considerations:  N/A
808    Published specification:  This specification (see Section 8.3.1).
809
810
811Section 8.3.1., paragraph 16:
812OLD:
813
814       File extension(s):  N/A
815       Macintosh file type code(s):  N/A
816
817NEW:
818
819       File extension(s):  N/A
820 
821       Macintosh file type code(s):  N/A
822
823
824Section 8.3.2., paragraph 12:
825OLD:
826
827    Applications that use this media type:  N/A
828    Fragment identifier considerations:  N/A
829
830NEW:
831
832    Applications that use this media type:  N/A
833 
834    Fragment identifier considerations:  N/A
835
836
837Section 8.4., paragraph 1:
838OLD:
839
840    The "HTTP Transfer Coding Registry" defines the namespace for
841    transfer coding names.  It is maintained at
842    <http://www.iana.org/assignments/http-parameters>.
843
844NEW:
845
846    The "HTTP Transfer Coding" registry defines the namespace for
847    transfer coding names.  It is maintained at
848    <http://www.iana.org/assignments/http-parameters>.
849
850
851Section 8.4.1., paragraph 2:
852OLD:
853
854    o  Name
855 
856    o  Description
857
858NEW:
859
860    o  Name
861    o  Description
862
863
864Section 8.5., paragraph 2:
865OLD:
866
867    The "HTTP Content Coding Registry" has been updated with the
868    registrations below:
869
870NEW:
871
872    The "HTTP Content Codings Registry" has been updated with the
873    registrations below:
874
875
876Section 8.6.2., paragraph 1:
877OLD:
878
879    The "HTTP" entry in the upgrade token registry has been updated with
880    the registration below:
881
882NEW:
883
884    The "HTTP" entry in the "HTTP Upgrade Token" registry shall be
885    updated with the registration below:
886
887
888Section 9.1., paragraph 3:
889OLD:
890
891    When a registered name is used in the authority component, the "http"
892    URI scheme (Section 2.7.1) relies on the user's local name resolution
893    service to determine where it can find authoritative responses.  This
894    means that any attack on a user's network host table, cached names,
895    or name resolution libraries becomes an avenue for attack on
896    establishing authority.  Likewise, the user's choice of server for
897    Domain Name Service (DNS), and the hierarchy of servers from which it
898    obtains resolution results, could impact the authenticity of address
899    mappings; DNS Security Extensions (DNSSEC, [RFC4033]) are one way to
900    improve authenticity.
901
902NEW:
903
904    When a registered name is used in the authority component, the "http"
905    URI scheme (Section 2.7.1) relies on the user's local name resolution
906    service to determine where it can find authoritative responses.  This
907    means that any attack on a user's network host table, cached names,
908    or name resolution libraries becomes an avenue for attack on
909    establishing authority.  Likewise, the user's choice of server for
910    Domain Name Service (DNS), and the hierarchy of servers from which it
911    obtains resolution results, could impact the authenticity of address
912    mappings; DNS Security Extensions (DNSSEC) ([RFC4033]) is one way to
913    improve authenticity.
914
915
916Section 9.2., paragraph 1:
917OLD:
918
919    By their very nature, HTTP intermediaries are men-in-the-middle, and
920    thus represent an opportunity for man-in-the-middle attacks.
921    Compromise of the systems on which the intermediaries run can result
922    in serious security and privacy problems.  Intermediaries might have
923    access to security-related information, personal information about
924    individual users and organizations, and proprietary information
925    belonging to users and content providers.  A compromised
926    intermediary, or an intermediary implemented or configured without
927    regard to security and privacy considerations, might be used in the
928    commission of a wide range of potential attacks.
929
930NEW:
931
932    By their very nature, HTTP intermediaries are men in the middle and,
933    thus, represent an opportunity for man-in-the-middle attacks.
934    Compromise of the systems on which the intermediaries run can result
935    in serious security and privacy problems.  Intermediaries might have
936    access to security-related information, personal information about
937    individual users and organizations, and proprietary information
938    belonging to users and content providers.  A compromised
939    intermediary, or an intermediary implemented or configured without
940    regard to security and privacy considerations, might be used in the
941    commission of a wide range of potential attacks.
942
943
944Section 9.6., paragraph 2:
945OLD:
946
947    User agents are encouraged to implement configurable means for
948    detecting and reporting failures of message integrity such that those
949    means can be enabled within environments for which integrity is
950    necessary.  For example, a browser being used to view medical history
951    or drug interaction information needs to indicate to the user when
952    such information is detected by the protocol to be incomplete,
953    expired, or corrupted during transfer.  Such mechanisms might be
954    selectively enabled via user agent extensions or the presence of
955    message integrity metadata in a response.  At a minimum, user agents
956    ought to provide some indication that allows a user to distinguish
957    between a complete and incomplete response message (Section 3.4) when
958    such verification is desired.
959
960NEW:
961
962    User agents are encouraged to implement configurable means for
963    detecting and reporting failures of message integrity such that those
964    means can be enabled within environments for which integrity is
965    necessary.  For example, a browser being used to view medical history
966    or drug interaction information needs to indicate to the user when
967    such information is detected by the protocol to be incomplete,
968    expired, or corrupted during transfer.  Such mechanisms might be
969    selectively enabled via user-agent extensions or the presence of
970    message integrity metadata in a response.  At a minimum, user agents
971    ought to provide some indication that allows a user to distinguish
972    between a complete and incomplete response message (Section 3.4) when
973    such verification is desired.
974
975
976Section 11.1., paragraph 1:
977OLD:
978
979    [RFC0793]     Postel, J., "Transmission Control Protocol", STD 7,
980                  RFC 793, September 1981.
981 
982    [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
983                  Format Specification version 3.3", RFC 1950, May 1996.
984
985NEW:
986
987    [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
988                  Format Specification version 3.3", RFC 1950, May 1996.
989
990
991Section 11.1., paragraph 7:
992OLD:
993
994    [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
995                  Transfer Protocol (HTTP/1.1): Semantics and Content",
996                  draft-ietf-httpbis-p2-semantics-latest (work in
997                  progress), May 2014.
998
999NEW:
1000
1001    [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1002                  Transfer Protocol (HTTP/1.1): Semantics and Content",
1003                  RFC 7231, May 2014.
1004
1005
1006Section 11.1., paragraph 8:
1007OLD:
1008
1009    [RFC7232]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1010                  Transfer Protocol (HTTP/1.1): Conditional Requests",
1011                  draft-ietf-httpbis-p4-conditional-latest (work in
1012                  progress), May 2014.
1013
1014NEW:
1015
1016    [RFC7232]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1017                  Transfer Protocol (HTTP/1.1): Conditional Requests",
1018                  RFC 7232, May 2014.
1019
1020
1021Section 11.1., paragraph 9:
1022OLD:
1023
1024    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1025                  "Hypertext Transfer Protocol (HTTP/1.1): Range
1026                  Requests", draft-ietf-httpbis-p5-range-latest (work in
1027                  progress), May 2014.
1028
1029NEW:
1030
1031    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1032                  "Hypertext Transfer Protocol (HTTP/1.1): Range
1033                  Requests", RFC 7233, May 2014.
1034
1035
1036Section 11.1., paragraph 10:
1037OLD:
1038
1039    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1040                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1041                  draft-ietf-httpbis-p6-cache-latest (work in progress),
1042                  May 2014.
1043
1044NEW:
1045
1046    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1047                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1048                  RFC 7234, May 2014.
1049
1050
1051Section 11.1., paragraph 11:
1052OLD:
1053
1054    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1055                  Transfer Protocol (HTTP/1.1): Authentication",
1056                  draft-ietf-httpbis-p7-auth-latest (work in progress),
1057                  May 2014.
1058
1059NEW:
1060
1061    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1062                  Transfer Protocol (HTTP/1.1): Authentication",
1063                  RFC 7235, May 2014.
1064 
1065    [RFC793]      Postel, J., "Transmission Control Protocol", STD 7,
1066                  RFC 793, September 1981.
1067
1068
1069Appendix A., paragraph 7:
1070OLD:
1071
1072 A.1.1.  Multi-homed Web Servers
1073
1074NEW:
1075
1076 A.1.1.  Multihomed Web Servers
1077
1078
1079Section 19.7.1, paragraph 8:
1080OLD:
1081
1082    HTTP's approach to error handling has been explained.  (Section 2.5)
1083
1084NEW:
1085
1086    HTTP's approach to error handling has been explained (Section 2.5).
1087
1088
1089Section 19.7.1, paragraph 9:
1090OLD:
1091
1092    The HTTP-version ABNF production has been clarified to be case-
1093    sensitive.  Additionally, version numbers have been restricted to
1094    single digits, due to the fact that implementations are known to
1095    handle multi-digit version numbers incorrectly.  (Section 2.6)
1096    Userinfo (i.e., username and password) are now disallowed in HTTP and
1097    HTTPS URIs, because of security issues related to their transmission
1098    on the wire.  (Section 2.7.1)
1099
1100NEW:
1101
1102    The HTTP-version ABNF production has been clarified to be case
1103    sensitive.  Additionally, version numbers have been restricted to
1104    single digits, due to the fact that implementations are known to
1105    handle multi-digit version numbers incorrectly (Section 2.6).
1106 
1107    Userinfo (i.e., username and password) are now disallowed in HTTP and
1108    HTTPS URIs, because of security issues related to their transmission
1109    on the wire (Section 2.7.1).
1110
1111
1112Section 19.7.1, paragraph 10:
1113OLD:
1114
1115    The HTTPS URI scheme is now defined by this specification;
1116    previously, it was done in Section 2.4 of [RFC2818].  Furthermore, it
1117    implies end-to-end security.  (Section 2.7.2)
1118
1119NEW:
1120
1121    The HTTPS URI scheme is now defined by this specification;
1122    previously, it was defined in Section 2.4 of [RFC2818].  Furthermore,
1123    it implies end-to-end security (Section 2.7.2).
1124
1125
1126Section 19.7.1, paragraph 11:
1127OLD:
1128
1129    HTTP messages can be (and often are) buffered by implementations;
1130    despite it sometimes being available as a stream, HTTP is
1131    fundamentally a message-oriented protocol.  Minimum supported sizes
1132    for various protocol elements have been suggested, to improve
1133    interoperability.  (Section 3)
1134
1135NEW:
1136
1137    HTTP messages can be (and often are) buffered by implementations;
1138    despite it sometimes being available as a stream, HTTP is
1139    fundamentally a message-oriented protocol.  Minimum supported sizes
1140    for various protocol elements have been suggested, to improve
1141    interoperability (Section 3).
1142
1143
1144Section 19.7.1, paragraph 12:
1145OLD:
1146
1147    Invalid whitespace around field-names is now required to be rejected,
1148    because accepting it represents a security vulnerability.  The ABNF
1149    productions defining header fields now only list the field value.
1150    (Section 3.2)
1151
1152NEW:
1153
1154    Invalid whitespace around field-names is now required to be rejected,
1155    because accepting it represents a security vulnerability.  The ABNF
1156    productions defining header fields now only list the field value
1157    (Section 3.2).
1158
1159
1160Section 19.7.1, paragraph 13:
1161OLD:
1162
1163    Rules about implicit linear whitespace between certain grammar
1164    productions have been removed; now whitespace is only allowed where
1165    specifically defined in the ABNF.  (Section 3.2.3)
1166
1167NEW:
1168
1169    Rules about implicit linear whitespace between certain grammar
1170    productions have been removed; now whitespace is only allowed where
1171    specifically defined in the ABNF (Section 3.2.3).
1172
1173
1174Section 19.7.1, paragraph 14:
1175OLD:
1176
1177    Header fields that span multiple lines ("line folding") are
1178    deprecated.  (Section 3.2.4)
1179
1180NEW:
1181
1182    Header fields that span multiple lines ("line folding") are
1183    deprecated (Section 3.2.4).
1184
1185
1186Section 19.7.1, paragraph 15:
1187OLD:
1188
1189    The NUL octet is no longer allowed in comment and quoted-string text,
1190    and handling of backslash-escaping in them has been clarified.  The
1191    quoted-pair rule no longer allows escaping control characters other
1192    than HTAB.  Non-US-ASCII content in header fields and the reason
1193    phrase has been obsoleted and made opaque (the TEXT rule was
1194    removed).  (Section 3.2.6)
1195
1196NEW:
1197
1198    The NUL octet is no longer allowed in comment and quoted-string text,
1199    and handling of backslash-escaping in them has been clarified.  The
1200    quoted-pair rule no longer allows escaping control characters other
1201    than HTAB.  Non-US-ASCII content in header fields and the reason
1202    phrase has been obsoleted and made opaque (the TEXT rule was removed)
1203    (Section 3.2.6).
1204
1205
1206Section 19.7.1, paragraph 16:
1207OLD:
1208
1209    Bogus "Content-Length" header fields are now required to be handled
1210    as errors by recipients.  (Section 3.3.2)
1211
1212NEW:
1213
1214    Bogus "Content-Length" header fields are now required to be handled
1215    as errors by recipients (Section 3.3.2).
1216
1217
1218Section 19.7.1, paragraph 17:
1219OLD:
1220
1221    The algorithm for determining the message body length has been
1222    clarified to indicate all of the special cases (e.g., driven by
1223    methods or status codes) that affect it, and that new protocol
1224    elements cannot define such special cases.  CONNECT is a new, special
1225    case in determining message body length. "multipart/byteranges" is no
1226    longer a way of determining message body length detection.
1227    (Section 3.3.3)
1228
1229NEW:
1230
1231    The algorithm for determining the message body length has been
1232    clarified to indicate all of the special cases (e.g., driven by
1233    methods or status codes) that affect it, and that new protocol
1234    elements cannot define such special cases.  CONNECT is a new, special
1235    case in determining message body length. "multipart/byteranges" is no
1236    longer a way of determining message body length detection
1237    (Section 3.3.3).
1238
1239
1240Section 19.7.1, paragraph 18:
1241OLD:
1242
1243    The "identity" transfer coding token has been removed.  (Sections 3.3
1244    and 4)
1245
1246NEW:
1247
1248    The "identity" transfer coding token has been removed (Sections 3.3
1249    and 4).
1250
1251
1252Section 19.7.1, paragraph 19:
1253OLD:
1254
1255    Chunk length does not include the count of the octets in the chunk
1256    header and trailer.  Line folding in chunk extensions is disallowed.
1257    (Section 4.1)
1258
1259NEW:
1260
1261    Chunk length does not include the count of the octets in the chunk
1262    header and trailer.  Line folding in chunk extensions is disallowed
1263    (Section 4.1).
1264
1265
1266Section 19.7.1, paragraph 20:
1267OLD:
1268
1269    The meaning of the "deflate" content coding has been clarified.
1270    (Section 4.2.2)
1271
1272NEW:
1273
1274    The meaning of the "deflate" content coding has been clarified
1275    (Section 4.2.2).
1276
1277
1278Section 19.7.1, paragraph 21:
1279OLD:
1280
1281    The segment + query components of RFC 3986 have been used to define
1282    the request-target, instead of abs_path from RFC 1808.  The asterisk-
1283    form of the request-target is only allowed with the OPTIONS method.
1284    (Section 5.3)
1285
1286NEW:
1287
1288    The segment + query components of RFC 3986 have been used to define
1289    the request-target, instead of abs_path from RFC 1808.  The asterisk-
1290    form of the request-target is only allowed with the OPTIONS method
1291    (Section 5.3).
1292
1293
1294Section 19.7.1, paragraph 22:
1295OLD:
1296
1297    The term "Effective Request URI" has been introduced.  (Section 5.5)
1298
1299NEW:
1300
1301    The term "Effective Request URI" has been introduced (Section 5.5).
1302
1303
1304Section 19.7.1, paragraph 23:
1305OLD:
1306
1307    Gateways do not need to generate Via header fields anymore.
1308    (Section 5.7.1)
1309
1310NEW:
1311
1312    Gateways do not need to generate Via header fields anymore
1313    (Section 5.7.1).
1314
1315
1316Section 19.7.1, paragraph 24:
1317OLD:
1318
1319    Exactly when "close" connection options have to be sent has been
1320    clarified.  Also, "hop-by-hop" header fields are required to appear
1321    in the Connection header field; just because they're defined as hop-
1322    by-hop in this specification doesn't exempt them.  (Section 6.1)
1323
1324NEW:
1325
1326    Exactly when "close" connection options have to be sent has been
1327    clarified.  Also, "hop-by-hop" header fields are required to appear
1328    in the Connection header field; just because they're defined as hop-
1329    by-hop in this specification doesn't exempt them (Section 6.1).
1330
1331
1332Section 19.7.1, paragraph 25:
1333OLD:
1334
1335    The limit of two connections per server has been removed.  An
1336    idempotent sequence of requests is no longer required to be retried.
1337    The requirement to retry requests under certain circumstances when
1338    the server prematurely closes the connection has been removed.  Also,
1339    some extraneous requirements about when servers are allowed to close
1340    connections prematurely have been removed.  (Section 6.3)
1341
1342NEW:
1343
1344    The limit of two connections per server has been removed.  An
1345    idempotent sequence of requests is no longer required to be retried.
1346    The requirement to retry requests under certain circumstances when
1347    the server prematurely closes the connection has been removed.  Also,
1348    some extraneous requirements about when servers are allowed to close
1349    connections prematurely have been removed (Section 6.3).
1350
1351
1352Section 19.7.1, paragraph 26:
1353OLD:
1354
1355    The semantics of the Upgrade header field is now defined in responses
1356    other than 101 (this was incorporated from [RFC2817]).  Furthermore,
1357    the ordering in the field value is now significant.  (Section 6.7)
1358
1359NEW:
1360
1361    The semantics of the Upgrade header field is now defined in responses
1362    other than 101 (this was incorporated from [RFC2817]).  Furthermore,
1363    the ordering in the field value is now significant (Section 6.7).
1364
1365
1366Section 19.7.1, paragraph 27:
1367OLD:
1368
1369    Empty list elements in list productions (e.g., a list header field
1370    containing ", ,") have been deprecated.  (Section 7)
1371
1372NEW:
1373
1374    Empty list elements in list productions (e.g., a list header field
1375    containing ", ,") have been deprecated (Section 7).
1376
1377
1378Section 19.7.1, paragraph 28:
1379OLD:
1380
1381    Registration of Transfer Codings now requires IETF Review
1382    (Section 8.4)
1383
1384NEW:
1385
1386    Registration of Transfer Codings now requires IETF Review
1387    (Section 8.4).
1388
1389
1390Section 19.7.1, paragraph 29:
1391OLD:
1392
1393    This specification now defines the Upgrade Token Registry, previously
1394    defined in Section 7.2 of [RFC2817].  (Section 8.6)
1395
1396NEW:
1397
1398    This specification now defines the "HTTP Upgrade Tokens" registry,
1399    previously defined in Section 7.2 of [RFC2817] (Section 8.6).
1400
1401
1402Section 19.7.1, paragraph 30:
1403OLD:
1404
1405    The expectation to support HTTP/0.9 requests has been removed.
1406    (Appendix A)
1407
1408NEW:
1409
1410    The expectation to support HTTP/0.9 requests has been removed
1411    (Appendix A).
1412
1413
1414Section 19.7.1, paragraph 31:
1415OLD:
1416
1417    Issues with the Keep-Alive and Proxy-Connection header fields in
1418    requests are pointed out, with use of the latter being discouraged
1419    altogether.  (Appendix A.1.2)
1420
1421NEW:
1422
1423    Issues with the Keep-Alive and Proxy-Connection header fields in
1424    requests are pointed out, with use of the latter being discouraged
1425    altogether (Appendix A.1.2).
1426
1427
1428Appendix B., paragraph 16:
1429OLD:
1430
1431    partial-URI = relative-part [ "?" query ]
1432    path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
1433    port = <port, defined in [RFC3986], Section 3.2.3>
1434    protocol = protocol-name [ "/" protocol-version ]
1435    protocol-name = token
1436    protocol-version = token
1437    pseudonym = token
1438 
1439    qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
1440     / %x5D-7E ; ']'-'~'
1441     / obs-text
1442    query = <query, defined in [RFC3986], Section 3.4>
1443    quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
1444    quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
1445
1446NEW:
1447
1448    partial-URI = relative-part [ "?" query ]
1449    path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
1450    port = <port, defined in [RFC3986], Section 3.2.3>
1451    protocol = protocol-name [ "/" protocol-version ]
1452    protocol-name = token
1453    protocol-version = token
1454    pseudonym = token
1455    qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
1456     / %x5D-7E ; ']'-'~'
1457     / obs-text
1458    query = <query, defined in [RFC3986], Section 3.4>
1459    quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
1460    quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
1461
1462
1463Appendix B., paragraph 22:
1464OLD:
1465
1466    A
1467       absolute-form (of request-target)  41
1468       accelerator  10
1469       application/http Media Type  62
1470       asterisk-form (of request-target)  42
1471       authoritative response  66
1472       authority-form (of request-target)  42
1473
1474NEW:
1475
1476    A
1477       absolute-form (of request-target)  42
1478       accelerator  10
1479       application/http Media Type  62
1480       asterisk-form (of request-target)  42
1481       authoritative response  66
1482       authority-form (of request-target)  42
1483
1484
1485Appendix B., paragraph 24:
1486OLD:
1487
1488    C
1489       cache  11
1490       cacheable  11
1491       captive portal  11
1492       chunked (Coding Format)  28, 31, 35
1493       client  7
1494       close  50, 55
1495       compress (Coding Format)  38
1496       connection  7
1497       Connection header field  50, 55
1498       Content-Length header field  29
1499
1500NEW:
1501
1502    C
1503       cache  11
1504       cacheable  11
1505       captive portal  11
1506       chunked (Coding Format)  28, 31, 35
1507       client  7
1508       close  50, 55
1509       compress (Coding Format)  38
1510       connection  7
1511       Connection header field  50, 55
1512       Content-Length header field  30
1513
1514
1515Appendix B., paragraph 25:
1516OLD:
1517
1518    D
1519       deflate (Coding Format)  38
1520       Delimiters  26
1521       downstream  9
1522
1523NEW:
1524
1525    D
1526       deflate (Coding Format)  38
1527       Delimiters  26
1528       downstream  10
1529
1530
1531Appendix B., paragraph 27:
1532OLD:
1533
1534    G
1535       gateway  10
1536       Grammar
1537          absolute-form  41
1538          absolute-path  16
1539          absolute-URI  16
1540          ALPHA  6
1541          asterisk-form  41-42
1542          authority  16
1543          authority-form  41-42
1544          BWS  24
1545          chunk  35
1546          chunk-data  35
1547          chunk-ext  35-36
1548          chunk-ext-name  36
1549          chunk-ext-val  36
1550          chunk-size  35
1551          chunked-body  35-36
1552          comment  27
1553          Connection  50
1554          connection-option  50
1555          Content-Length  29
1556          CR  6
1557          CRLF  6
1558          ctext  27
1559          CTL  6
1560          DIGIT  6
1561          DQUOTE  6
1562          field-content  22
1563          field-name  22, 39
1564          field-value  22
1565          field-vchar  22
1566          fragment  16
1567          header-field  22, 36
1568          HEXDIG  6
1569          Host  43
1570          HTAB  6
1571          HTTP-message  19
1572          HTTP-name  13
1573          http-URI  16
1574          HTTP-version  13
1575          https-URI  18
1576          last-chunk  35
1577          LF  6
1578          message-body  27
1579          method  21
1580          obs-fold  22
1581          obs-text  27
1582          OCTET  6
1583          origin-form  41
1584          OWS  24
1585          partial-URI  16
1586          port  16
1587          protocol-name  47
1588          protocol-version  47
1589          pseudonym  47
1590          qdtext  27
1591          query  16
1592          quoted-pair  27
1593          quoted-string  27
1594          rank  38
1595          reason-phrase  22
1596          received-by  47
1597          received-protocol  47
1598          request-line  21
1599          request-target  41
1600          RWS  24
1601          scheme  16
1602          segment  16
1603          SP  6
1604          start-line  20
1605          status-code  22
1606          status-line  22
1607          t-codings  38
1608          t-ranking  38
1609          tchar  26
1610          TE  38
1611          token  26
1612          Trailer  39
1613          trailer-part  35-36
1614          transfer-coding  35
1615          Transfer-Encoding  28
1616          transfer-extension  35
1617          transfer-parameter  35
1618          Upgrade  56
1619          uri-host  16
1620          URI-reference  16
1621          VCHAR  6
1622          Via  47
1623 
1624       gzip (Coding Format)  38
1625
1626NEW:
1627
1628    G
1629       gateway  10
1630       Grammar
1631          absolute-form  41-42
1632          absolute-path  16
1633          absolute-URI  16
1634          ALPHA  6
1635          asterisk-form  41-42
1636          authority  16
1637          authority-form  41-42
1638          BWS  24
1639          chunk  35
1640          chunk-data  35
1641          chunk-ext  35-36
1642          chunk-ext-name  36
1643          chunk-ext-val  36
1644          chunk-size  35
1645          chunked-body  35-36
1646          comment  27
1647          Connection  51
1648          connection-option  51
1649          Content-Length  30
1650          CR  6
1651          CRLF  6
1652          ctext  27
1653          CTL  6
1654          DIGIT  6
1655          DQUOTE  6
1656          field-content  22
1657          field-name  22, 39
1658          field-value  22
1659          field-vchar  22
1660          fragment  16
1661          header-field  22, 36
1662          HEXDIG  6
1663          Host  43
1664          HTAB  6
1665          HTTP-message  19
1666          HTTP-name  14
1667          http-URI  16
1668          HTTP-version  14
1669          https-URI  18
1670          last-chunk  35
1671          LF  6
1672          message-body  27
1673          method  21
1674          obs-fold  22
1675          obs-text  27
1676          OCTET  6
1677          origin-form  41
1678          OWS  24
1679          partial-URI  16
1680          port  16
1681          protocol-name  47
1682          protocol-version  47
1683          pseudonym  47
1684          qdtext  27
1685          query  16
1686          quoted-pair  27
1687          quoted-string  27
1688          rank  38
1689          reason-phrase  22
1690          received-by  47
1691          received-protocol  47
1692          request-line  21
1693          request-target  41
1694          RWS  24
1695          scheme  16
1696          segment  16
1697          SP  6
1698          start-line  20
1699          status-code  22
1700          status-line  22
1701          t-codings  38
1702          t-ranking  38
1703          tchar  27
1704          TE  38
1705          token  27
1706          Trailer  39
1707          trailer-part  35-36
1708          transfer-coding  35
1709          Transfer-Encoding  28
1710          transfer-extension  35
1711          transfer-parameter  35
1712          Upgrade  56
1713          uri-host  16
1714          URI-reference  16
1715          VCHAR  6
1716          Via  47
1717       gzip (Coding Format)  38
1718
1719
1720Appendix B., paragraph 29:
1721OLD:
1722
1723    I
1724       inbound  9
1725       interception proxy  11
1726       intermediary  9
1727
1728NEW:
1729
1730    I
1731       inbound  10
1732       interception proxy  11
1733       intermediary  9
1734
1735
1736Appendix B., paragraph 32:
1737OLD:
1738
1739    O
1740       origin server  7
1741       origin-form (of request-target)  41
1742       outbound  9
1743
1744NEW:
1745
1746    O
1747       origin server  7
1748       origin-form (of request-target)  41
1749       outbound  10
1750
1751
1752Appendix B., paragraph 37:
1753OLD:
1754
1755    U
1756       Upgrade header field  56
1757       upstream  9
1758       URI scheme
1759          http  16
1760          https  18
1761       user agent  7
1762
1763NEW:
1764
1765    U
1766       Upgrade header field  56
1767       upstream  10
1768       URI scheme
1769          http  16
1770          https  18
1771       user agent  7
1772
1773
1774Appendix B., paragraph 38:
1775OLD:
1776
1777    V
1778       Via header field  46
1779
1780NEW:
1781
1782    V
1783       Via header field  47
1784
1785
1786Section 345, paragraph 1:
1787OLD:
1788
1789    EMail: fielding@gbiv.com
1790    URI:   http://roy.gbiv.com/
1791 
1792    Julian F. Reschke (editor)
1793    greenbytes GmbH
1794    Hafenweg 16
1795    Muenster, NW  48155
1796    Germany
1797
1798NEW:
1799
1800    EMail: fielding@gbiv.com
1801    URI:   http://roy.gbiv.com/
1802    Julian F. Reschke (editor)
1803    greenbytes GmbH
1804    Hafenweg 16
1805    Muenster, NW  48155
1806    Germany
1807
Note: See TracBrowser for help on using the repository browser.