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

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

s/transport or session-layer/transport- or session-layer/ (#553)

File size: 63.4 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 Header Field
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.1., paragraph 2:
811OLD:
812
813    This document defines the following HTTP header fields, so their
814    associated registry entries has been updated according to the
815    permanent registrations below (see [BCP90]):
816
817NEW:
818
819    This document defines the following HTTP header fields, so the
820    "Permanent Message Header Field Names" registry has been updated
821    accordingly (see [BCP90]).
822
823
824Section 8.2., paragraph 2:
825OLD:
826
827    This document defines the following URI schemes, so their associated
828    registry entries has been updated according to the permanent
829    registrations below:
830
831NEW:
832
833    This document defines the following URI schemes, so the "Permanent
834    URI Schemes" registry has been updated accordingly.
835
836
837Section 8.4., paragraph 1:
838OLD:
839
840    The HTTP Transfer Coding Registry defines the namespace for transfer
841    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.2., paragraph 1:
852OLD:
853
854    The HTTP Transfer Coding Registry has been updated with the
855    registrations below:
856
857NEW:
858
859    The "HTTP Transfer Coding Registry" has been updated with the
860    registrations below:
861
862
863Section 8.5., paragraph 1:
864OLD:
865
866    IANA maintains the registry of HTTP Content Codings at
867    <http://www.iana.org/assignments/http-parameters>.
868
869NEW:
870
871    IANA maintains the "HTTP Content Coding Registry" at
872    <http://www.iana.org/assignments/http-parameters>.
873
874
875Section 8.5., paragraph 2:
876OLD:
877
878    The HTTP Content Codings Registry has been updated with the
879    registrations below:
880
881NEW:
882
883    The "HTTP Content Codings Registry" has been updated with the
884    registrations below:
885
886
887Section 8.6., paragraph 1:
888OLD:
889
890    The HTTP Upgrade Token Registry defines the namespace for protocol-
891    name tokens used to identify protocols in the Upgrade header field.
892    The registry is maintained at
893    <http://www.iana.org/assignments/http-upgrade-tokens>.
894
895NEW:
896
897    The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
898    defines the namespace for protocol-name tokens used to identify
899    protocols in the Upgrade header field.  The registry is maintained at
900    <http://www.iana.org/assignments/http-upgrade-tokens>.
901
902
903Section 8.6.2., paragraph 1:
904OLD:
905
906    The "HTTP" entry in the HTTP Upgrade Token Registry has been updated
907    with the registration below:
908
909NEW:
910
911    The "HTTP" entry in the "HTTP Upgrade Token" registry shall be
912    updated with the registration below:
913
914
915Section 9.1., paragraph 3:
916OLD:
917
918    When a registered name is used in the authority component, the "http"
919    URI scheme (Section 2.7.1) relies on the user's local name resolution
920    service to determine where it can find authoritative responses.  This
921    means that any attack on a user's network host table, cached names,
922    or name resolution libraries becomes an avenue for attack on
923    establishing authority.  Likewise, the user's choice of server for
924    Domain Name Service (DNS), and the hierarchy of servers from which it
925    obtains resolution results, could impact the authenticity of address
926    mappings; DNS Security Extensions (DNSSEC, [RFC4033]) are one way to
927    improve authenticity.
928
929NEW:
930
931    When a registered name is used in the authority component, the "http"
932    URI scheme (Section 2.7.1) relies on the user's local name resolution
933    service to determine where it can find authoritative responses.  This
934    means that any attack on a user's network host table, cached names,
935    or name resolution libraries becomes an avenue for attack on
936    establishing authority.  Likewise, the user's choice of server for
937    Domain Name Service (DNS), and the hierarchy of servers from which it
938    obtains resolution results, could impact the authenticity of address
939    mappings; DNS Security Extensions (DNSSEC) ([RFC4033]) is one way to
940    improve authenticity.
941
942
943Section 9.2., paragraph 1:
944OLD:
945
946    By their very nature, HTTP intermediaries are men-in-the-middle, and
947    thus represent an opportunity for man-in-the-middle attacks.
948    Compromise of the systems on which the intermediaries run can result
949    in serious security and privacy problems.  Intermediaries might have
950    access to security-related information, personal information about
951    individual users and organizations, and proprietary information
952    belonging to users and content providers.  A compromised
953    intermediary, or an intermediary implemented or configured without
954    regard to security and privacy considerations, might be used in the
955    commission of a wide range of potential attacks.
956
957NEW:
958
959    By their very nature, HTTP intermediaries are men in the middle and,
960    thus, represent an opportunity for man-in-the-middle attacks.
961    Compromise of the systems on which the intermediaries run can result
962    in serious security and privacy problems.  Intermediaries might have
963    access to security-related information, personal information about
964    individual users and organizations, and proprietary information
965    belonging to users and content providers.  A compromised
966    intermediary, or an intermediary implemented or configured without
967    regard to security and privacy considerations, might be used in the
968    commission of a wide range of potential attacks.
969
970
971Section 9.6., paragraph 2:
972OLD:
973
974    User agents are encouraged to implement configurable means for
975    detecting and reporting failures of message integrity such that those
976    means can be enabled within environments for which integrity is
977    necessary.  For example, a browser being used to view medical history
978    or drug interaction information needs to indicate to the user when
979    such information is detected by the protocol to be incomplete,
980    expired, or corrupted during transfer.  Such mechanisms might be
981    selectively enabled via user agent extensions or the presence of
982    message integrity metadata in a response.  At a minimum, user agents
983    ought to provide some indication that allows a user to distinguish
984    between a complete and incomplete response message (Section 3.4) when
985    such verification is desired.
986
987NEW:
988
989    User agents are encouraged to implement configurable means for
990    detecting and reporting failures of message integrity such that those
991    means can be enabled within environments for which integrity is
992    necessary.  For example, a browser being used to view medical history
993    or drug interaction information needs to indicate to the user when
994    such information is detected by the protocol to be incomplete,
995    expired, or corrupted during transfer.  Such mechanisms might be
996    selectively enabled via user-agent extensions or the presence of
997    message integrity metadata in a response.  At a minimum, user agents
998    ought to provide some indication that allows a user to distinguish
999    between a complete and incomplete response message (Section 3.4) when
1000    such verification is desired.
1001
1002
1003Section 11.1., paragraph 1:
1004OLD:
1005
1006    [RFC0793]     Postel, J., "Transmission Control Protocol", STD 7,
1007                  RFC 793, September 1981.
1008 
1009    [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
1010                  Format Specification version 3.3", RFC 1950, May 1996.
1011
1012NEW:
1013
1014    [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
1015                  Format Specification version 3.3", RFC 1950, May 1996.
1016
1017
1018Section 11.1., paragraph 7:
1019OLD:
1020
1021    [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1022                  Transfer Protocol (HTTP/1.1): Semantics and Content",
1023                  draft-ietf-httpbis-p2-semantics-latest (work in
1024                  progress), May 2014.
1025
1026NEW:
1027
1028    [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1029                  Transfer Protocol (HTTP/1.1): Semantics and Content",
1030                  RFC 7231, May 2014.
1031
1032
1033Section 11.1., paragraph 8:
1034OLD:
1035
1036    [RFC7232]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1037                  Transfer Protocol (HTTP/1.1): Conditional Requests",
1038                  draft-ietf-httpbis-p4-conditional-latest (work in
1039                  progress), May 2014.
1040
1041NEW:
1042
1043    [RFC7232]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1044                  Transfer Protocol (HTTP/1.1): Conditional Requests",
1045                  RFC 7232, May 2014.
1046
1047
1048Section 11.1., paragraph 9:
1049OLD:
1050
1051    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1052                  "Hypertext Transfer Protocol (HTTP/1.1): Range
1053                  Requests", draft-ietf-httpbis-p5-range-latest (work in
1054                  progress), May 2014.
1055
1056NEW:
1057
1058    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1059                  "Hypertext Transfer Protocol (HTTP/1.1): Range
1060                  Requests", RFC 7233, May 2014.
1061
1062
1063Section 11.1., paragraph 10:
1064OLD:
1065
1066    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1067                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1068                  draft-ietf-httpbis-p6-cache-latest (work in progress),
1069                  May 2014.
1070
1071NEW:
1072
1073    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1074                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1075                  RFC 7234, May 2014.
1076
1077
1078Section 11.1., paragraph 11:
1079OLD:
1080
1081    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1082                  Transfer Protocol (HTTP/1.1): Authentication",
1083                  draft-ietf-httpbis-p7-auth-latest (work in progress),
1084                  May 2014.
1085
1086NEW:
1087
1088    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1089                  Transfer Protocol (HTTP/1.1): Authentication",
1090                  RFC 7235, May 2014.
1091 
1092    [RFC793]      Postel, J., "Transmission Control Protocol", STD 7,
1093                  RFC 793, September 1981.
1094
1095
1096Appendix A., paragraph 7:
1097OLD:
1098
1099 A.1.1.  Multi-homed Web Servers
1100
1101NEW:
1102
1103 A.1.1.  Multihomed Web Servers
1104
1105
1106Section 19.7.1, paragraph 8:
1107OLD:
1108
1109    HTTP's approach to error handling has been explained.  (Section 2.5)
1110
1111NEW:
1112
1113    HTTP's approach to error handling has been explained (Section 2.5).
1114
1115
1116Section 19.7.1, paragraph 9:
1117OLD:
1118
1119    The HTTP-version ABNF production has been clarified to be case-
1120    sensitive.  Additionally, version numbers have been restricted to
1121    single digits, due to the fact that implementations are known to
1122    handle multi-digit version numbers incorrectly.  (Section 2.6)
1123
1124NEW:
1125
1126    The HTTP-version ABNF production has been clarified to be case
1127    sensitive.  Additionally, version numbers have been restricted to
1128    single digits, due to the fact that implementations are known to
1129    handle multi-digit version numbers incorrectly (Section 2.6).
1130
1131
1132Section 19.7.1, paragraph 10:
1133OLD:
1134
1135    Userinfo (i.e., username and password) are now disallowed in HTTP and
1136    HTTPS URIs, because of security issues related to their transmission
1137    on the wire.  (Section 2.7.1)
1138
1139NEW:
1140
1141    Userinfo (i.e., username and password) are now disallowed in HTTP and
1142    HTTPS URIs, because of security issues related to their transmission
1143    on the wire (Section 2.7.1).
1144
1145
1146Section 19.7.1, paragraph 11:
1147OLD:
1148
1149    The HTTPS URI scheme is now defined by this specification;
1150    previously, it was done in Section 2.4 of [RFC2818].  Furthermore, it
1151    implies end-to-end security.  (Section 2.7.2)
1152
1153NEW:
1154
1155    The HTTPS URI scheme is now defined by this specification;
1156    previously, it was defined in Section 2.4 of [RFC2818].  Furthermore,
1157    it implies end-to-end security (Section 2.7.2).
1158
1159
1160Section 19.7.1, paragraph 12:
1161OLD:
1162
1163    HTTP messages can be (and often are) buffered by implementations;
1164    despite it sometimes being available as a stream, HTTP is
1165    fundamentally a message-oriented protocol.  Minimum supported sizes
1166    for various protocol elements have been suggested, to improve
1167    interoperability.  (Section 3)
1168
1169NEW:
1170
1171    HTTP messages can be (and often are) buffered by implementations;
1172    despite it sometimes being available as a stream, HTTP is
1173    fundamentally a message-oriented protocol.  Minimum supported sizes
1174    for various protocol elements have been suggested, to improve
1175    interoperability (Section 3).
1176
1177
1178Section 19.7.1, paragraph 13:
1179OLD:
1180
1181    Invalid whitespace around field-names is now required to be rejected,
1182    because accepting it represents a security vulnerability.  The ABNF
1183    productions defining header fields now only list the field value.
1184    (Section 3.2)
1185
1186NEW:
1187
1188    Invalid whitespace around field-names is now required to be rejected,
1189    because accepting it represents a security vulnerability.  The ABNF
1190    productions defining header fields now only list the field value
1191    (Section 3.2).
1192
1193
1194Section 19.7.1, paragraph 14:
1195OLD:
1196
1197    Rules about implicit linear whitespace between certain grammar
1198    productions have been removed; now whitespace is only allowed where
1199    specifically defined in the ABNF.  (Section 3.2.3)
1200
1201NEW:
1202
1203    Rules about implicit linear whitespace between certain grammar
1204    productions have been removed; now whitespace is only allowed where
1205    specifically defined in the ABNF (Section 3.2.3).
1206
1207
1208Section 19.7.1, paragraph 15:
1209OLD:
1210
1211    Header fields that span multiple lines ("line folding") are
1212    deprecated.  (Section 3.2.4)
1213    The NUL octet is no longer allowed in comment and quoted-string text,
1214    and handling of backslash-escaping in them has been clarified.  The
1215    quoted-pair rule no longer allows escaping control characters other
1216    than HTAB.  Non-US-ASCII content in header fields and the reason
1217    phrase has been obsoleted and made opaque (the TEXT rule was
1218    removed).  (Section 3.2.6)
1219
1220NEW:
1221
1222    Header fields that span multiple lines ("line folding") are
1223    deprecated (Section 3.2.4).
1224 
1225    The NUL octet is no longer allowed in comment and quoted-string text,
1226    and handling of backslash-escaping in them has been clarified.  The
1227    quoted-pair rule no longer allows escaping control characters other
1228    than HTAB.  Non-US-ASCII content in header fields and the reason
1229    phrase has been obsoleted and made opaque (the TEXT rule was removed)
1230    (Section 3.2.6).
1231
1232
1233Section 19.7.1, paragraph 16:
1234OLD:
1235
1236    Bogus "Content-Length" header fields are now required to be handled
1237    as errors by recipients.  (Section 3.3.2)
1238
1239NEW:
1240
1241    Bogus "Content-Length" header fields are now required to be handled
1242    as errors by recipients (Section 3.3.2).
1243
1244
1245Section 19.7.1, paragraph 17:
1246OLD:
1247
1248    The algorithm for determining the message body length has been
1249    clarified to indicate all of the special cases (e.g., driven by
1250    methods or status codes) that affect it, and that new protocol
1251    elements cannot define such special cases.  CONNECT is a new, special
1252    case in determining message body length. "multipart/byteranges" is no
1253    longer a way of determining message body length detection.
1254    (Section 3.3.3)
1255
1256NEW:
1257
1258    The algorithm for determining the message body length has been
1259    clarified to indicate all of the special cases (e.g., driven by
1260    methods or status codes) that affect it, and that new protocol
1261    elements cannot define such special cases.  CONNECT is a new, special
1262    case in determining message body length. "multipart/byteranges" is no
1263    longer a way of determining message body length detection
1264    (Section 3.3.3).
1265
1266
1267Section 19.7.1, paragraph 18:
1268OLD:
1269
1270    The "identity" transfer coding token has been removed.  (Sections 3.3
1271    and 4)
1272
1273NEW:
1274
1275    The "identity" transfer coding token has been removed (Sections 3.3
1276    and 4).
1277
1278
1279Section 19.7.1, paragraph 19:
1280OLD:
1281
1282    Chunk length does not include the count of the octets in the chunk
1283    header and trailer.  Line folding in chunk extensions is disallowed.
1284    (Section 4.1)
1285
1286NEW:
1287
1288    Chunk length does not include the count of the octets in the chunk
1289    header and trailer.  Line folding in chunk extensions is disallowed
1290    (Section 4.1).
1291
1292
1293Section 19.7.1, paragraph 20:
1294OLD:
1295
1296    The meaning of the "deflate" content coding has been clarified.
1297    (Section 4.2.2)
1298
1299NEW:
1300
1301    The meaning of the "deflate" content coding has been clarified
1302    (Section 4.2.2).
1303
1304
1305Section 19.7.1, paragraph 21:
1306OLD:
1307
1308    The segment + query components of RFC 3986 have been used to define
1309    the request-target, instead of abs_path from RFC 1808.  The asterisk-
1310    form of the request-target is only allowed with the OPTIONS method.
1311    (Section 5.3)
1312
1313NEW:
1314
1315    The segment + query components of RFC 3986 have been used to define
1316    the request-target, instead of abs_path from RFC 1808.  The asterisk-
1317    form of the request-target is only allowed with the OPTIONS method
1318    (Section 5.3).
1319
1320
1321Section 19.7.1, paragraph 22:
1322OLD:
1323
1324    The term "Effective Request URI" has been introduced.  (Section 5.5)
1325
1326NEW:
1327
1328    The term "Effective Request URI" has been introduced (Section 5.5).
1329
1330
1331Section 19.7.1, paragraph 23:
1332OLD:
1333
1334    Gateways do not need to generate Via header fields anymore.
1335    (Section 5.7.1)
1336
1337NEW:
1338
1339    Gateways do not need to generate Via header fields anymore
1340    (Section 5.7.1).
1341
1342
1343Section 19.7.1, paragraph 24:
1344OLD:
1345
1346    Exactly when "close" connection options have to be sent has been
1347    clarified.  Also, "hop-by-hop" header fields are required to appear
1348    in the Connection header field; just because they're defined as hop-
1349    by-hop in this specification doesn't exempt them.  (Section 6.1)
1350
1351NEW:
1352
1353    Exactly when "close" connection options have to be sent has been
1354    clarified.  Also, "hop-by-hop" header fields are required to appear
1355    in the Connection header field; just because they're defined as hop-
1356    by-hop in this specification doesn't exempt them (Section 6.1).
1357
1358
1359Section 19.7.1, paragraph 25:
1360OLD:
1361
1362    The limit of two connections per server has been removed.  An
1363    idempotent sequence of requests is no longer required to be retried.
1364    The requirement to retry requests under certain circumstances when
1365    the server prematurely closes the connection has been removed.  Also,
1366    some extraneous requirements about when servers are allowed to close
1367    connections prematurely have been removed.  (Section 6.3)
1368
1369NEW:
1370
1371    The limit of two connections per server has been removed.  An
1372    idempotent sequence of requests is no longer required to be retried.
1373    The requirement to retry requests under certain circumstances when
1374    the server prematurely closes the connection has been removed.  Also,
1375    some extraneous requirements about when servers are allowed to close
1376    connections prematurely have been removed (Section 6.3).
1377
1378
1379Section 19.7.1, paragraph 26:
1380OLD:
1381
1382    The semantics of the Upgrade header field is now defined in responses
1383    other than 101 (this was incorporated from [RFC2817]).  Furthermore,
1384    the ordering in the field value is now significant.  (Section 6.7)
1385
1386NEW:
1387
1388    The semantics of the Upgrade header field is now defined in responses
1389    other than 101 (this was incorporated from [RFC2817]).  Furthermore,
1390    the ordering in the field value is now significant (Section 6.7).
1391
1392
1393Section 19.7.1, paragraph 27:
1394OLD:
1395
1396    Empty list elements in list productions (e.g., a list header field
1397    containing ", ,") have been deprecated.  (Section 7)
1398
1399NEW:
1400
1401    Empty list elements in list productions (e.g., a list header field
1402    containing ", ,") have been deprecated (Section 7).
1403
1404
1405Section 19.7.1, paragraph 28:
1406OLD:
1407
1408    Registration of Transfer Codings now requires IETF Review
1409    (Section 8.4)
1410
1411NEW:
1412
1413    Registration of Transfer Codings now requires IETF Review
1414    (Section 8.4).
1415
1416
1417Section 19.7.1, paragraph 29:
1418OLD:
1419
1420    This specification now defines the Upgrade Token Registry, previously
1421    defined in Section 7.2 of [RFC2817].  (Section 8.6)
1422
1423NEW:
1424
1425    This specification now defines the "HTTP Upgrade Tokens" registry,
1426    previously defined in Section 7.2 of [RFC2817] (Section 8.6).
1427
1428
1429Section 19.7.1, paragraph 30:
1430OLD:
1431
1432    The expectation to support HTTP/0.9 requests has been removed.
1433    (Appendix A)
1434
1435NEW:
1436
1437    The expectation to support HTTP/0.9 requests has been removed
1438    (Appendix A).
1439
1440
1441Section 19.7.1, paragraph 31:
1442OLD:
1443
1444    Issues with the Keep-Alive and Proxy-Connection header fields in
1445    requests are pointed out, with use of the latter being discouraged
1446    altogether.  (Appendix A.1.2)
1447
1448NEW:
1449
1450    Issues with the Keep-Alive and Proxy-Connection header fields in
1451    requests are pointed out, with use of the latter being discouraged
1452    altogether (Appendix A.1.2).
1453
1454
1455Appendix B., paragraph 7:
1456OLD:
1457
1458    URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
1459    Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
1460    Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
1461     ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
1462     comment ] ) ] )
1463
1464NEW:
1465
1466    URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
1467    Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
1468 
1469    Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
1470     ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
1471     comment ] ) ] )
1472
1473
1474Appendix B., paragraph 15:
1475OLD:
1476
1477    partial-URI = relative-part [ "?" query ]
1478    path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
1479    port = <port, defined in [RFC3986], Section 3.2.3>
1480    protocol = protocol-name [ "/" protocol-version ]
1481    protocol-name = token
1482    protocol-version = token
1483    pseudonym = token
1484 
1485    qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
1486     / %x5D-7E ; ']'-'~'
1487     / obs-text
1488    query = <query, defined in [RFC3986], Section 3.4>
1489    quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
1490    quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
1491
1492NEW:
1493
1494    partial-URI = relative-part [ "?" query ]
1495    path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
1496    port = <port, defined in [RFC3986], Section 3.2.3>
1497    protocol = protocol-name [ "/" protocol-version ]
1498    protocol-name = token
1499    protocol-version = token
1500    pseudonym = token
1501    qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
1502     / %x5D-7E ; ']'-'~'
1503     / obs-text
1504    query = <query, defined in [RFC3986], Section 3.4>
1505    quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
1506    quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
1507
1508
1509Appendix B., paragraph 24:
1510OLD:
1511
1512    D
1513       deflate (Coding Format)  38
1514       Delimiters  26
1515       downstream  9
1516
1517NEW:
1518
1519    D
1520       deflate (Coding Format)  38
1521       Delimiters  26
1522       downstream  10
1523
1524
1525Appendix B., paragraph 26:
1526OLD:
1527
1528    G
1529       gateway  10
1530       Grammar
1531          absolute-form  41-42
1532          absolute-path  16
1533          absolute-URI  16
1534          ALPHA  6
1535          asterisk-form  41-42
1536          authority  16
1537          authority-form  41-42
1538          BWS  24
1539          chunk  35
1540          chunk-data  35
1541          chunk-ext  35-36
1542          chunk-ext-name  36
1543          chunk-ext-val  36
1544          chunk-size  35
1545          chunked-body  35-36
1546          comment  27
1547          Connection  51
1548          connection-option  51
1549          Content-Length  30
1550          CR  6
1551          CRLF  6
1552          ctext  27
1553          CTL  6
1554          DIGIT  6
1555          DQUOTE  6
1556          field-content  22
1557          field-name  22, 39
1558          field-value  22
1559          field-vchar  22
1560          fragment  16
1561          header-field  22, 36
1562          HEXDIG  6
1563          Host  43
1564          HTAB  6
1565          HTTP-message  19
1566          HTTP-name  13
1567          http-URI  16
1568          HTTP-version  13
1569          https-URI  18
1570          last-chunk  35
1571          LF  6
1572          message-body  27
1573          method  21
1574          obs-fold  22
1575          obs-text  27
1576          OCTET  6
1577          origin-form  41
1578          OWS  24
1579          partial-URI  16
1580          port  16
1581          protocol-name  47
1582          protocol-version  47
1583          pseudonym  47
1584          qdtext  27
1585          query  16
1586          quoted-pair  27
1587          quoted-string  27
1588          rank  38
1589          reason-phrase  22
1590          received-by  47
1591          received-protocol  47
1592          request-line  21
1593          request-target  41
1594          RWS  24
1595          scheme  16
1596          segment  16
1597          SP  6
1598          start-line  20
1599          status-code  22
1600          status-line  22
1601          t-codings  38
1602          t-ranking  38
1603          tchar  27
1604          TE  38
1605          token  27
1606          Trailer  39
1607          trailer-part  35-36
1608          transfer-coding  35
1609          Transfer-Encoding  28
1610          transfer-extension  35
1611          transfer-parameter  35
1612          Upgrade  56
1613          uri-host  16
1614          URI-reference  16
1615          VCHAR  6
1616          Via  47
1617       gzip (Coding Format)  38
1618
1619NEW:
1620
1621    G
1622       gateway  10
1623       Grammar
1624          absolute-form  41-42
1625          absolute-path  16
1626          absolute-URI  16
1627          ALPHA  6
1628          asterisk-form  41-42
1629          authority  16
1630          authority-form  41-42
1631          BWS  24
1632          chunk  35
1633          chunk-data  35
1634          chunk-ext  35-36
1635          chunk-ext-name  36
1636          chunk-ext-val  36
1637          chunk-size  35
1638          chunked-body  35-36
1639          comment  27
1640          Connection  51
1641          connection-option  51
1642          Content-Length  30
1643          CR  6
1644          CRLF  6
1645          ctext  27
1646          CTL  6
1647          DIGIT  6
1648          DQUOTE  6
1649          field-content  22
1650          field-name  22, 39
1651          field-value  22
1652          field-vchar  22
1653          fragment  16
1654          header-field  22, 36
1655          HEXDIG  6
1656          Host  43
1657          HTAB  6
1658          HTTP-message  19
1659          HTTP-name  14
1660          http-URI  16
1661          HTTP-version  14
1662          https-URI  18
1663          last-chunk  35
1664          LF  6
1665          message-body  27
1666          method  21
1667          obs-fold  22
1668          obs-text  27
1669          OCTET  6
1670          origin-form  41
1671          OWS  24
1672          partial-URI  16
1673          port  16
1674          protocol-name  47
1675          protocol-version  47
1676          pseudonym  47
1677          qdtext  27
1678          query  16
1679          quoted-pair  27
1680          quoted-string  27
1681          rank  38
1682          reason-phrase  22
1683          received-by  47
1684          received-protocol  47
1685          request-line  21
1686          request-target  41
1687          RWS  24
1688          scheme  16
1689          segment  16
1690          SP  6
1691          start-line  20
1692          status-code  22
1693          status-line  22
1694          t-codings  38
1695          t-ranking  38
1696          tchar  27
1697          TE  38
1698          token  27
1699          Trailer  39
1700          trailer-part  35-36
1701          transfer-coding  35
1702          Transfer-Encoding  28
1703          transfer-extension  35
1704          transfer-parameter  35
1705          Upgrade  56
1706          uri-host  16
1707          URI-reference  16
1708          VCHAR  6
1709          Via  47
1710       gzip (Coding Format)  38
1711
1712
1713Appendix B., paragraph 28:
1714OLD:
1715
1716    I
1717       inbound  9
1718       interception proxy  11
1719       intermediary  9
1720
1721NEW:
1722
1723    I
1724       inbound  10
1725       interception proxy  11
1726       intermediary  9
1727
1728
1729Appendix B., paragraph 31:
1730OLD:
1731
1732    O
1733       origin server  7
1734       origin-form (of request-target)  41
1735       outbound  9
1736
1737NEW:
1738
1739    O
1740       origin server  7
1741       origin-form (of request-target)  41
1742       outbound  10
1743
1744
1745Appendix B., paragraph 36:
1746OLD:
1747
1748    U
1749       Upgrade header field  56
1750       upstream  9
1751       URI scheme
1752          http  16
1753          https  18
1754       user agent  7
1755
1756NEW:
1757
1758    U
1759       Upgrade header field  56
1760       upstream  10
1761       URI scheme
1762          http  16
1763          https  18
1764       user agent  7
1765
1766
1767Section 345, paragraph 1:
1768OLD:
1769
1770    EMail: fielding@gbiv.com
1771    URI:   http://roy.gbiv.com/
1772 
1773    Julian F. Reschke (editor)
1774    greenbytes GmbH
1775    Hafenweg 16
1776    Muenster, NW  48155
1777    Germany
1778
1779NEW:
1780
1781    EMail: fielding@gbiv.com
1782    URI:   http://roy.gbiv.com/
1783    Julian F. Reschke (editor)
1784    greenbytes GmbH
1785    Hafenweg 16
1786    Muenster, NW  48155
1787    Germany
1788
Note: See TracBrowser for help on using the repository browser.