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

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

expand a few status code mentions (#553)

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