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

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

consistently quote connection options (#553)

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