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

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

registry names (see #553)

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