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

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

hyphenation/spacing (#553)

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