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

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

Abbreviations (#553)

File size: 76.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 6, 2014
10 Intended status: Standards Track
11 Expires: November 7, 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 7, 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.3., paragraph 11:
377OLD:
378
379    HTTP is defined as a stateless protocol, meaning that each request
380    message can be understood in isolation.  Many implementations depend
381    on HTTP's stateless design in order to reuse proxied connections or
382    dynamically load-balance requests across multiple servers.  Hence, a
383    server MUST NOT assume that two requests on the same connection are
384    from the same user agent unless the connection is secured and
385    specific to that agent.  Some non-standard HTTP extensions (e.g.,
386    [RFC4559]) have been known to violate this requirement, resulting in
387    security and interoperability problems.
388
389NEW:
390
391    HTTP is defined as a stateless protocol, meaning that each request
392    message can be understood in isolation.  Many implementations depend
393    on HTTP's stateless design in order to reuse proxied connections or
394    dynamically load balance requests across multiple servers.  Hence, a
395    server MUST NOT assume that two requests on the same connection are
396    from the same user agent unless the connection is secured and
397    specific to that agent.  Some non-standard HTTP extensions (e.g.,
398    [RFC4559]) have been known to violate this requirement, resulting in
399    security and interoperability problems.
400
401
402Section 2.6., paragraph 2:
403OLD:
404
405    The version of an HTTP message is indicated by an HTTP-version field
406    in the first line of the message.  HTTP-version is case-sensitive.
407
408NEW:
409
410    The version of an HTTP message is indicated by an HTTP-version field
411    in the first line of the message.  HTTP-version is case sensitive.
412
413
414Section 2.6., paragraph 3:
415OLD:
416
417      HTTP-version  = HTTP-name "/" DIGIT "." DIGIT
418      HTTP-name     = %x48.54.54.50 ; "HTTP", case-sensitive
419
420NEW:
421
422      HTTP-version  = HTTP-name "/" DIGIT "." DIGIT
423      HTTP-name     = %x48.54.54.50 ; "HTTP", case sensitive
424
425
426Section 2.6., paragraph 7:
427OLD:
428
429    New header fields can be introduced without changing the protocol
430    version if their defined semantics allow them to be safely ignored by
431    recipients that do not recognize them.  Header field extensibility is
432    discussed in Section 3.2.1.
433
434NEW:
435
436    New header fields can be introduced without changing the protocol
437    version if their defined semantics allow them to be safely ignored by
438    recipients that do not recognize them.  Header-field extensibility is
439    discussed in Section 3.2.1.
440
441
442Section 2.6., paragraph 14:
443OLD:
444
445    When an HTTP message is received with a major version number that the
446    recipient implements, but a higher minor version number than what the
447    recipient implements, the recipient SHOULD process the message as if
448    it were in the highest minor version within that major version to
449    which the recipient is conformant.  A recipient can assume that a
450    message with a higher minor version, when sent to a recipient that
451    has not yet indicated support for that higher version, is
452    sufficiently backwards-compatible to be safely processed by any
453    implementation of the same major version.
454
455NEW:
456
457    When an HTTP message is received with a major version number that the
458    recipient implements, but a higher minor version number than what the
459    recipient implements, the recipient SHOULD process the message as if
460    it were in the highest minor version within that major version to
461    which the recipient is conformant.  A recipient can assume that a
462    message with a higher minor version, when sent to a recipient that
463    has not yet indicated support for that higher version, is
464    sufficiently backwards compatible to be safely processed by any
465    implementation of the same major version.
466
467
468Section 2.7., paragraph 2:
469OLD:
470
471    The definitions of "URI-reference", "absolute-URI", "relative-part",
472    "scheme", "authority", "port", "host", "path-abempty", "segment",
473    "query", and "fragment" are adopted from the URI generic syntax.  An
474    "absolute-path" rule is defined for protocol elements that can
475    contain a non-empty path component.  (This rule differs slightly from
476    RFC 3986's path-abempty rule, which allows for an empty path to be
477    used in references, and path-absolute rule, which does not allow
478    paths that begin with "//".)  A "partial-URI" rule is defined for
479    protocol elements that can contain a relative URI but not a fragment
480    component.
481
482NEW:
483
484    The definitions of "URI-reference", "absolute-URI", "relative-part",
485    "scheme", "authority", "port", "host", "path-abempty", "segment",
486    "query", and "fragment" are adopted from the URI generic syntax.  An
487    "absolute-path" rule is defined for protocol elements that can
488    contain a non-empty path component.  (This rule differs slightly from
489    the path-abempty rule of RFC 3986, which allows for an empty path to
490    be used in references, and path-absolute rule, which does not allow
491    paths that begin with "//".)  A "partial-URI" rule is defined for
492    protocol elements that can contain a relative URI but not a fragment
493    component.
494
495
496Section 2.7.1., paragraph 1:
497OLD:
498
499    The "http" URI scheme is hereby defined for the purpose of minting
500    identifiers according to their association with the hierarchical
501    namespace governed by a potential HTTP origin server listening for
502    TCP ([RFC0793]) connections on a given port.
503
504NEW:
505
506    The "http" URI scheme is hereby defined for the purpose of minting
507    identifiers according to their association with the hierarchical
508    namespace governed by a potential HTTP origin server listening for
509    TCP ([RFC793]) connections on a given port.
510
511
512Section 2.1, paragraph 0:
513OLD:
514
515    If the port is equal to the default port for a scheme, the normal
516    form is to omit the port subcomponent.  When not being used in
517    absolute form as the request target of an OPTIONS request, an empty
518    path component is equivalent to an absolute path of "/", so the
519    normal form is to provide a path of "/" instead.  The scheme and host
520    are case-insensitive and normally provided in lowercase; all other
521    components are compared in a case-sensitive manner.  Characters other
522    than those in the "reserved" set are equivalent to their percent-
523    encoded octets: the normal form is to not encode them (see Sections
524    2.1 and 2.2 of [RFC3986]).
525
526NEW:
527
528    If the port is equal to the default port for a scheme, the normal
529    form is to omit the port subcomponent.  When not being used in
530    absolute form as the request target of an OPTIONS request, an empty
531    path component is equivalent to an absolute path of "/", so the
532    normal form is to provide a path of "/" instead.  The scheme and host
533    are case insensitive and normally provided in lowercase; all other
534    components are compared in a case-sensitive manner.  Characters other
535    than those in the "reserved" set are equivalent to their percent-
536    encoded octets: the normal form is to not encode them (see Sections
537    2.1 and 2.2 of [RFC3986]).
538
539
540Section 3.1., paragraph 2:
541OLD:
542
543    In theory, a client could receive requests and a server could receive
544    responses, distinguishing them by their different start-line formats,
545    but, in practice, servers are implemented to only expect a request (a
546    response is interpreted as an unknown or invalid request method) and
547    clients are implemented to only expect a response.
548
549NEW:
550
551    In theory, a client could receive requests and a server could receive
552    responses, distinguishing them by their different start-line formats,
553    but, in practice, servers are implemented only to expect a request (a
554    response is interpreted as an unknown or invalid request method) and
555    clients are implemented to only expect a response.
556
557
558Section 3.1.1., paragraph 1:
559OLD:
560
561    A request-line begins with a method token, followed by a single space
562    (SP), the request-target, another single space (SP), the protocol
563    version, and ending with CRLF.
564
565NEW:
566
567    A request-line begins with a method token and is followed by a single
568    space (SP), the request-target, another single space (SP), the
569    protocol version, and ends with CRLF.
570
571
572Section 3.1.1., paragraph 3:
573OLD:
574
575    The method token indicates the request method to be performed on the
576    target resource.  The request method is case-sensitive.
577
578NEW:
579
580    The method token indicates the request method to be performed on the
581    target resource.  The request method is case sensitive.
582
583
584Section 3.1.2., paragraph 1:
585OLD:
586
587    The first line of a response message is the status-line, consisting
588    of the protocol version, a space (SP), the status code, another
589    space, a possibly empty textual phrase describing the status code,
590    and ending with CRLF.
591
592NEW:
593
594    The first line of a response message is the status-line, consisting
595    of the protocol version, a space (SP), the status code, another space
596    (SP), a possibly empty textual phrase describing the status code,
597    and, finally, CRLF.
598
599
600Section 3.2.1., paragraph 4:
601OLD:
602
603    All defined header fields ought to be registered with IANA in the
604    Message Header Field Registry, as described in Section 8.3 of
605    [RFC7231].
606
607NEW:
608
609    All defined header fields ought to be registered with IANA in the
610    "Message Headers" field registry, as described in Section 8.3 of
611    [RFC7231].
612
613
614Section 3.2.2., paragraph 4:
615OLD:
616
617       Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
618       appears multiple times in a response message and does not use the
619       list syntax, violating the above requirements on multiple header
620       fields with the same name.  Since it cannot be combined into a
621       single field-value, recipients ought to handle "Set-Cookie" as a
622       special case while processing header fields.  (See Appendix A.2.3
623       of [Kri2001] for details.)
624
625NEW:
626
627       Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
628       appears multiple times in a response message and does not use the
629       list syntax, violating the above requirements on multiple header
630       fields with the same name.  Since it cannot be combined into a
631       single field-value, recipients ought to handle Set-Cookie as a
632       special case while processing header fields.  (See Appendix A.2.3
633       of [Kri2001] for details.)
634
635
636Section 3.2.3., paragraph 2:
637OLD:
638
639    The OWS rule is used where zero or more linear whitespace octets
640    might appear.  For protocol elements where optional whitespace is
641    preferred to improve readability, a sender SHOULD generate the
642    optional whitespace as a single SP; otherwise, a sender SHOULD NOT
643    generate optional whitespace except as needed to white-out invalid or
644    unwanted protocol elements during in-place message filtering.
645
646NEW:
647
648    The OWS rule is used where zero or more linear whitespace octets
649    might appear.  For protocol elements where optional whitespace is
650    preferred to improve readability, a sender SHOULD generate the
651    optional whitespace as a single SP; otherwise, a sender SHOULD NOT
652    generate optional whitespace except as needed to white out invalid or
653    unwanted protocol elements during in-place message filtering.
654
655
656Section 3.2.4., paragraph 1:
657OLD:
658
659    Messages are parsed using a generic algorithm, independent of the
660    individual header field names.  The contents within a given field
661    value are not parsed until a later stage of message interpretation
662    (usually after the message's entire header section has been
663    processed).  Consequently, this specification does not use ABNF rules
664    to define each "Field-Name: Field Value" pair, as was done in
665    previous editions.  Instead, this specification uses ABNF rules that
666    are named according to each registered field name, wherein the rule
667    defines the valid grammar for that field's corresponding field values
668    (i.e., after the field-value has been extracted from the header
669    section by a generic field parser).
670
671NEW:
672
673    Messages are parsed using a generic algorithm, independent of the
674    individual header field names.  The contents within a given field
675    value are not parsed until a later stage of message interpretation
676    (usually after the message's entire header section has been
677    processed).  Consequently, this specification does not use ABNF rules
678    to define each "field-name: field-value" pair, as was done in
679    previous editions.  Instead, this specification uses ABNF rules that
680    are named according to each registered field name, wherein the rule
681    defines the valid grammar for that field's corresponding field values
682    (i.e., after the field-value has been extracted from the header
683    section by a generic field parser).
684
685
686Section 3.2.4., paragraph 8:
687OLD:
688
689    Historically, HTTP has allowed field content with text in the
690    ISO-8859-1 charset [ISO-8859-1], supporting other charsets only
691    through use of [RFC2047] encoding.  In practice, most HTTP header
692    field values use only a subset of the US-ASCII charset [USASCII].
693    Newly defined header fields SHOULD limit their field values to
694    US-ASCII octets.  A recipient SHOULD treat other octets in field
695    content (obs-text) as opaque data.
696
697NEW:
698
699    Historically, HTTP has allowed field content with text in the
700    ISO-8859-1 [ISO-8859-1] charset, supporting other charsets only
701    through use of [RFC2047] encoding.  In practice, most HTTP header
702    field values use only a subset of the US-ASCII charset [USASCII].
703    Newly defined header fields SHOULD limit their field values to
704    US-ASCII octets.  A recipient SHOULD treat other octets in field
705    content (obs-text) as opaque data.
706
707
708Section 7., paragraph 1:
709OLD:
710
711    Since there is no way to distinguish a successfully completed, close-
712    delimited message from a partially-received message interrupted by
713    network failure, a server SHOULD generate encoding or length-
714    delimited messages whenever possible.  The close-delimiting feature
715    exists primarily for backwards compatibility with HTTP/1.0.
716
717NEW:
718
719    Since there is no way to distinguish a successfully completed, close-
720    delimited message from a partially received message interrupted by
721    network failure, a server SHOULD generate encoding or length-
722    delimited messages whenever possible.  The close-delimiting feature
723    exists primarily for backwards compatibility with HTTP/1.0.
724
725
726Section 4., paragraph 5:
727OLD:
728
729    All transfer-coding names are case-insensitive and ought to be
730    registered within the HTTP Transfer Coding registry, as defined in
731    Section 8.4.  They are used in the TE (Section 4.3) and Transfer-
732    Encoding (Section 3.3.1) header fields.
733
734NEW:
735
736    All transfer-coding names are case insensitive and ought to be
737    registered within the "HTTP Transfer Coding" registry, as defined in
738    Section 8.4.  They are used in the TE (Section 4.3) and Transfer-
739    Encoding (Section 3.3.1) header fields.
740
741
742Section 5.7.2., paragraph 6:
743OLD:
744
745    A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of
746    a message that contains a no-transform cache-control directive
747    (Section 5.2 of [RFC7234]).
748
749NEW:
750
751    A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of
752    a message that contains a no-transform Cache-Control directive
753    (Section 5.2 of [RFC7234]).
754
755
756Section 200, paragraph 0:
757OLD:
758
759    A proxy MAY transform the payload of a message that does not contain
760    a no-transform cache-control directive.  A proxy that transforms a
761    payload MUST add a Warning header field with the warn-code of 214
762    ("Transformation Applied") if one is not already in the message (see
763    Section 5.5 of [RFC7234]).  A proxy that transforms the payload of a
764    200 (OK) response can further inform downstream recipients that a
765    transformation has been applied by changing the response status code
766    to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).
767
768NEW:
769
770    A proxy MAY transform the payload of a message that does not contain
771    a no-transform Cache-Control directive.  A proxy that transforms a
772    payload MUST add a Warning header field with the warn-code of 214
773    ("Transformation Applied") if one is not already in the message (see
774    Section 5.5 of [RFC7234]).  A proxy that transforms the payload of a
775    200 (OK) response can further inform downstream recipients that a
776    transformation has been applied by changing the response status code
777    to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).
778
779
780Section 6., paragraph 1:
781OLD:
782
783    HTTP messaging is independent of the underlying transport or session-
784    layer connection protocol(s).  HTTP only presumes a reliable
785    transport with in-order delivery of requests and the corresponding
786    in-order delivery of responses.  The mapping of HTTP request and
787    response structures onto the data units of an underlying transport
788    protocol is outside the scope of this specification.
789
790NEW:
791
792    HTTP messaging is independent of the underlying transport- or
793    session-layer connection protocol(s).  HTTP only presumes a reliable
794    transport with in-order delivery of requests and the corresponding
795    in-order delivery of responses.  The mapping of HTTP request and
796    response structures onto the data units of an underlying transport
797    protocol is outside the scope of this specification.
798
799
800Section 6.1., paragraph 6:
801OLD:
802
803    Connection options are case-insensitive.
804
805NEW:
806
807    Connection options are case insensitive.
808
809
810Section 6.2., paragraph 1:
811OLD:
812
813    It is beyond the scope of this specification to describe how
814    connections are established via various transport or session-layer
815    protocols.  Each connection applies to only one transport link.
816
817NEW:
818
819    It is beyond the scope of this specification to describe how
820    connections are established via various transport- or session-layer
821    protocols.  Each connection applies to only one transport link.
822
823
824Section 6.3., paragraph 1:
825OLD:
826
827    HTTP/1.1 defaults to the use of "persistent connections", allowing
828    multiple requests and responses to be carried over a single
829    connection.  The "close" connection-option is used to signal that a
830    connection will not persist after the current request/response.  HTTP
831    implementations SHOULD support persistent connections.
832
833NEW:
834
835    HTTP/1.1 defaults to the use of "persistent connections", allowing
836    multiple requests and responses to be carried over a single
837    connection.  The "close" connection option is used to signal that a
838    connection will not persist after the current request/response.  HTTP
839    implementations SHOULD support persistent connections.
840
841
842Section 6.3., paragraph 3:
843OLD:
844
845    o  If the close connection option is present, the connection will not
846       persist after the current response; else,
847
848NEW:
849
850    o  If the "close" connection option is present, the connection will
851       not persist after the current response; else,
852
853
854Section 6.3., paragraph 7:
855OLD:
856
857    A client MAY send additional requests on a persistent connection
858    until it sends or receives a close connection option or receives an
859    HTTP/1.0 response without a "keep-alive" connection option.
860
861NEW:
862
863    A client MAY send additional requests on a persistent connection
864    until it sends or receives a "close" connection option or receives an
865    HTTP/1.0 response without a "keep-alive" connection option.
866
867
868Section 6.5., paragraph 4:
869OLD:
870
871    A server SHOULD sustain persistent connections, when possible, and
872    allow the underlying transport's flow control mechanisms to resolve
873    temporary overloads, rather than terminate connections with the
874    expectation that clients will retry.  The latter technique can
875    exacerbate network congestion.
876
877NEW:
878
879    A server SHOULD sustain persistent connections, when possible, and
880    allow the underlying transport's flow-control mechanisms to resolve
881    temporary overloads, rather than terminate connections with the
882    expectation that clients will retry.  The latter technique can
883    exacerbate network congestion.
884
885
886Section 6.5., paragraph 6:
887OLD:
888
889 6.6.  Tear-down
890
891NEW:
892
893 6.6.  Teardown
894
895
896Section 6.5., paragraph 8:
897OLD:
898
899    A client that sends a close connection option MUST NOT send further
900    requests on that connection (after the one containing close) and MUST
901    close the connection after reading the final response message
902    corresponding to this request.
903
904NEW:
905
906    A client that sends a "close" connection option MUST NOT send further
907    requests on that connection (after the one containing close) and MUST
908    close the connection after reading the final response message
909    corresponding to this request.
910
911
912Section 6.5., paragraph 9:
913OLD:
914
915    A server that receives a close connection option MUST initiate a
916    close of the connection (see below) after it sends the final response
917    to the request that contained close.  The server SHOULD send a close
918    connection option in its final response on that connection.  The
919    server MUST NOT process any further requests received on that
920    connection.
921
922NEW:
923
924    A server that receives a "close" connection option MUST initiate a
925    close of the connection (see below) after it sends the final response
926    to the request that contained close.  The server SHOULD send a close
927    connection option in its final response on that connection.  The
928    server MUST NOT process any further requests received on that
929    connection.
930
931
932Section 6.5., paragraph 10:
933OLD:
934
935    A server that sends a close connection option MUST initiate a close
936    of the connection (see below) after it sends the response containing
937    close.  The server MUST NOT process any further requests received on
938    that connection.
939
940NEW:
941
942    A server that sends a "close" connection option MUST initiate a close
943    of the connection (see below) after it sends the response containing
944    close.  The server MUST NOT process any further requests received on
945    that connection.
946
947
948Section 6.5., paragraph 11:
949OLD:
950
951    A client that receives a close connection option MUST cease sending
952    requests on that connection and close the connection after reading
953    the response message containing the close; if additional pipelined
954    requests had been sent on the connection, the client SHOULD NOT
955    assume that they will be processed by the server.
956
957NEW:
958
959    A client that receives a "close" connection option MUST cease sending
960    requests on that connection and close the connection after reading
961    the response message containing the close; if additional pipelined
962    requests had been sent on the connection, the client SHOULD NOT
963    assume that they will be processed by the server.
964
965
966Section 6.5., paragraph 12:
967OLD:
968
969    If a server performs an immediate close of a TCP connection, there is
970    a significant risk that the client will not be able to read the last
971    HTTP response.  If the server receives additional data from the
972    client on a fully-closed connection, such as another request that was
973    sent by the client before receiving the server's response, the
974    server's TCP stack will send a reset packet to the client;
975    unfortunately, the reset packet might erase the client's
976    unacknowledged input buffers before they can be read and interpreted
977    by the client's HTTP parser.
978
979NEW:
980
981    If a server performs an immediate close of a TCP connection, there is
982    a significant risk that the client will not be able to read the last
983    HTTP response.  If the server receives additional data from the
984    client on a fully closed connection, such as another request that was
985    sent by the client before receiving the server's response, the
986    server's TCP stack will send a reset packet to the client;
987    unfortunately, the reset packet might erase the client's
988    unacknowledged input buffers before they can be read and interpreted
989    by the client's HTTP parser.
990
991
992Section 6.7., paragraph 9:
993OLD:
994
995    The capabilities and nature of the application-level communication
996    after the protocol change is entirely dependent upon the new
997    protocol(s) chosen.  However, immediately after sending the 101
998    response, the server is expected to continue responding to the
999    original request as if it had received its equivalent within the new
1000    protocol (i.e., the server still has an outstanding request to
1001    satisfy after the protocol has been changed, and is expected to do so
1002    without requiring the request to be repeated).
1003
1004NEW:
1005
1006    The capabilities and nature of the application-level communication
1007    after the protocol change is entirely dependent upon the new
1008    protocol(s) chosen.  However, immediately after sending the 101
1009    (Switching Protocols) response, the server is expected to continue
1010    responding to the original request as if it had received its
1011    equivalent within the new protocol (i.e., the server still has an
1012    outstanding request to satisfy after the protocol has been changed,
1013    and is expected to do so without requiring the request to be
1014    repeated).
1015
1016
1017Section 7., paragraph 14:
1018OLD:
1019
1020    Then the following are valid values for example-list (not including
1021    the double quotes, which are present for delimitation only):
1022
1023NEW:
1024
1025    Then, the following are valid values for example-list (not including
1026    the double quotes, which are present for delimitation only):
1027
1028
1029Section 8.1., paragraph 1:
1030OLD:
1031
1032    HTTP header fields are registered within the Message Header Field
1033    Registry maintained at
1034    <http://www.iana.org/assignments/message-headers/>.
1035
1036NEW:
1037
1038    HTTP header fields are registered within the "Message Header" field
1039    registry maintained at
1040    <http://www.iana.org/assignments/message-headers/>.
1041
1042
1043Section 8.1., paragraph 2:
1044OLD:
1045
1046    This document defines the following HTTP header fields, so their
1047    associated registry entries shall be updated according to the
1048    permanent registrations below (see [BCP90]):
1049
1050NEW:
1051
1052    This document defines the following HTTP header fields, so the
1053    "Permanent Message Header Field Names" registry has been updated
1054    accordingly (see [BCP90]).
1055
1056
1057Section 8.1., paragraph 4:
1058OLD:
1059
1060    Furthermore, the header field-name "Close" shall be registered as
1061    "reserved", since using that name as an HTTP header field might
1062    conflict with the "close" connection option of the "Connection"
1063    header field (Section 6.1).
1064
1065NEW:
1066
1067    Furthermore, the header field-name "Close" has been registered as
1068    "reserved", since using that name as an HTTP header field might
1069    conflict with the "close" connection option of the "Connection"
1070    header field (Section 6.1).
1071
1072
1073Section 8.2., paragraph 2:
1074OLD:
1075
1076    This document defines the following URI schemes, so their associated
1077    registry entries shall be updated according to the permanent
1078    registrations below:
1079
1080NEW:
1081
1082    This document defines the following URI schemes, so the "Permanent
1083    URI Schemes" registry has been updated accordingly.
1084
1085
1086Section 8.3., paragraph 2:
1087OLD:
1088
1089    This document serves as the specification for the Internet media
1090    types "message/http" and "application/http".  The following is to be
1091    registered with IANA.
1092
1093NEW:
1094
1095    This document serves as the specification for the Internet media
1096    types "message/http" and "application/http".  The following has been
1097    registered with IANA.
1098
1099
1100Section 8.3.1., paragraph 18:
1101OLD:
1102
1103    Person and email address to contact for further information:  See
1104       Authors' Addresses Section.
1105
1106NEW:
1107
1108    Person and email address to contact for further information:
1109       See Authors' Addresses  Section.
1110
1111
1112Section 8.3.2., paragraph 8:
1113OLD:
1114
1115    Encoding considerations:  HTTP messages enclosed by this type are in
1116       "binary" format; use of an appropriate Content-Transfer-Encoding
1117       is required when transmitted via E-mail.
1118
1119NEW:
1120
1121    Encoding considerations:  HTTP messages enclosed by this type are in
1122       "binary" format; use of an appropriate Content-Transfer-Encoding
1123       is required when transmitted via email.
1124
1125
1126Section 8.3.2., paragraph 19:
1127OLD:
1128
1129    Person and email address to contact for further information:  See
1130       Authors' Addresses Section.
1131
1132NEW:
1133
1134    Person and email address to contact for further information:
1135       See Authors' Addresses Section.
1136
1137
1138Section 8.4., paragraph 1:
1139OLD:
1140
1141    The HTTP Transfer Coding Registry defines the name space for transfer
1142    coding names.  It is maintained at
1143    <http://www.iana.org/assignments/http-parameters>.
1144
1145NEW:
1146
1147    The "HTTP Transfer Coding" registry defines the namespace for
1148    transfer coding names.  It is maintained at
1149    <http://www.iana.org/assignments/http-parameters>.
1150
1151
1152Section 8.4.1., paragraph 5:
1153OLD:
1154
1155    Values to be added to this name space require IETF Review (see
1156    Section 4.1 of [RFC5226]), and MUST conform to the purpose of
1157    transfer coding defined in this specification.
1158
1159NEW:
1160
1161    Values to be added to this namespace require IETF Review (see Section
1162    4.1 of [RFC5226]), and MUST conform to the purpose of transfer coding
1163    defined in this specification.
1164
1165
1166Section 8.4.2., paragraph 1:
1167OLD:
1168
1169    The HTTP Transfer Coding Registry shall be updated with the
1170    registrations below:
1171
1172NEW:
1173
1174    The "HTTP Transfer Coding Registry" has been updated with the
1175    registrations below:
1176
1177
1178Section 8.5., paragraph 1:
1179OLD:
1180
1181    IANA maintains the registry of HTTP Content Codings at
1182    <http://www.iana.org/assignments/http-parameters>.
1183
1184NEW:
1185
1186    IANA maintains the "HTTP Content Coding Registry" at
1187    <http://www.iana.org/assignments/http-parameters>.
1188
1189
1190Section 8.5., paragraph 2:
1191OLD:
1192
1193    The HTTP Content Codings Registry shall be updated with the
1194    registrations below:
1195
1196NEW:
1197
1198    The "HTTP Content Codings Registry" has been updated with the
1199    registrations below:
1200
1201
1202Section 8.6., paragraph 1:
1203OLD:
1204
1205    The HTTP Upgrade Token Registry defines the name space for protocol-
1206    name tokens used to identify protocols in the Upgrade header field.
1207    The registry is maintained at
1208    <http://www.iana.org/assignments/http-upgrade-tokens>.
1209
1210NEW:
1211
1212    The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
1213    defines the namespace for protocol-name tokens used to identify
1214    protocols in the Upgrade header field.  The registry is maintained at
1215    <http://www.iana.org/assignments/http-upgrade-tokens>.
1216
1217
1218Section 8.6.2., paragraph 1:
1219OLD:
1220
1221    The "HTTP" entry in the HTTP Upgrade Token Registry shall be updated
1222    with the registration below:
1223
1224NEW:
1225
1226    The "HTTP" entry in the "HTTP Upgrade Token" registry shall be
1227    updated with the registration below:
1228
1229
1230Section 9.1., paragraph 3:
1231OLD:
1232
1233    When a registered name is used in the authority component, the "http"
1234    URI scheme (Section 2.7.1) relies on the user's local name resolution
1235    service to determine where it can find authoritative responses.  This
1236    means that any attack on a user's network host table, cached names,
1237    or name resolution libraries becomes an avenue for attack on
1238    establishing authority.  Likewise, the user's choice of server for
1239    Domain Name Service (DNS), and the hierarchy of servers from which it
1240    obtains resolution results, could impact the authenticity of address
1241    mappings; DNS Security Extensions (DNSSEC, [RFC4033]) are one way to
1242    improve authenticity.
1243
1244NEW:
1245
1246    When a registered name is used in the authority component, the "http"
1247    URI scheme (Section 2.7.1) relies on the user's local name resolution
1248    service to determine where it can find authoritative responses.  This
1249    means that any attack on a user's network host table, cached names,
1250    or name resolution libraries becomes an avenue for attack on
1251    establishing authority.  Likewise, the user's choice of server for
1252    Domain Name Service (DNS), and the hierarchy of servers from which it
1253    obtains resolution results, could impact the authenticity of address
1254    mappings; DNS Security Extensions (DNSSEC) ([RFC4033]) is one way to
1255    improve authenticity.
1256
1257
1258Section 9.2., paragraph 1:
1259OLD:
1260
1261    By their very nature, HTTP intermediaries are men-in-the-middle, and
1262    thus represent an opportunity for man-in-the-middle attacks.
1263    Compromise of the systems on which the intermediaries run can result
1264    in serious security and privacy problems.  Intermediaries might have
1265    access to security-related information, personal information about
1266    individual users and organizations, and proprietary information
1267    belonging to users and content providers.  A compromised
1268    intermediary, or an intermediary implemented or configured without
1269    regard to security and privacy considerations, might be used in the
1270    commission of a wide range of potential attacks.
1271
1272NEW:
1273
1274    By their very nature, HTTP intermediaries are men in the middle and,
1275    thus, represent an opportunity for man-in-the-middle attacks.
1276    Compromise of the systems on which the intermediaries run can result
1277    in serious security and privacy problems.  Intermediaries might have
1278    access to security-related information, personal information about
1279    individual users and organizations, and proprietary information
1280    belonging to users and content providers.  A compromised
1281    intermediary, or an intermediary implemented or configured without
1282    regard to security and privacy considerations, might be used in the
1283    commission of a wide range of potential attacks.
1284
1285
1286Section 9.6., paragraph 2:
1287OLD:
1288
1289    User agents are encouraged to implement configurable means for
1290    detecting and reporting failures of message integrity such that those
1291    means can be enabled within environments for which integrity is
1292    necessary.  For example, a browser being used to view medical history
1293    or drug interaction information needs to indicate to the user when
1294    such information is detected by the protocol to be incomplete,
1295    expired, or corrupted during transfer.  Such mechanisms might be
1296    selectively enabled via user agent extensions or the presence of
1297    message integrity metadata in a response.  At a minimum, user agents
1298    ought to provide some indication that allows a user to distinguish
1299    between a complete and incomplete response message (Section 3.4) when
1300    such verification is desired.
1301
1302NEW:
1303
1304    User agents are encouraged to implement configurable means for
1305    detecting and reporting failures of message integrity such that those
1306    means can be enabled within environments for which integrity is
1307    necessary.  For example, a browser being used to view medical history
1308    or drug interaction information needs to indicate to the user when
1309    such information is detected by the protocol to be incomplete,
1310    expired, or corrupted during transfer.  Such mechanisms might be
1311    selectively enabled via user-agent extensions or the presence of
1312    message integrity metadata in a response.  At a minimum, user agents
1313    ought to provide some indication that allows a user to distinguish
1314    between a complete and incomplete response message (Section 3.4) when
1315    such verification is desired.
1316
1317
1318Section 11.1., paragraph 1:
1319OLD:
1320
1321    [RFC0793]     Postel, J., "Transmission Control Protocol", STD 7,
1322                  RFC 793, September 1981.
1323 
1324    [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
1325                  Format Specification version 3.3", RFC 1950, May 1996.
1326
1327NEW:
1328
1329    [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
1330                  Format Specification version 3.3", RFC 1950, May 1996.
1331
1332
1333Section 11.1., paragraph 7:
1334OLD:
1335
1336    [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1337                  Transfer Protocol (HTTP/1.1): Semantics and Content",
1338                  draft-ietf-httpbis-p2-semantics-latest (work in
1339                  progress), May 2014.
1340
1341NEW:
1342
1343    [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1344                  Transfer Protocol (HTTP/1.1): Semantics and Content",
1345                  RFC 7231, May 2014.
1346
1347
1348Section 11.1., paragraph 8:
1349OLD:
1350
1351    [RFC7232]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1352                  Transfer Protocol (HTTP/1.1): Conditional Requests",
1353                  draft-ietf-httpbis-p4-conditional-latest (work in
1354                  progress), May 2014.
1355
1356NEW:
1357
1358    [RFC7232]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1359                  Transfer Protocol (HTTP/1.1): Conditional Requests",
1360                  RFC 7232, May 2014.
1361
1362
1363Section 11.1., paragraph 9:
1364OLD:
1365
1366    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1367                  "Hypertext Transfer Protocol (HTTP/1.1): Range
1368                  Requests", draft-ietf-httpbis-p5-range-latest (work in
1369                  progress), May 2014.
1370
1371NEW:
1372
1373    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1374                  "Hypertext Transfer Protocol (HTTP/1.1): Range
1375                  Requests", RFC 7233, May 2014.
1376
1377
1378Section 11.1., paragraph 10:
1379OLD:
1380
1381    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1382                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1383                  draft-ietf-httpbis-p6-cache-latest (work in progress),
1384                  May 2014.
1385
1386NEW:
1387
1388    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1389                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1390                  RFC 7234, May 2014.
1391
1392
1393Section 11.1., paragraph 11:
1394OLD:
1395
1396    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1397                  Transfer Protocol (HTTP/1.1): Authentication",
1398                  draft-ietf-httpbis-p7-auth-latest (work in progress),
1399                  May 2014.
1400
1401NEW:
1402
1403    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1404                  Transfer Protocol (HTTP/1.1): Authentication",
1405                  RFC 7235, May 2014.
1406 
1407    [RFC793]      Postel, J., "Transmission Control Protocol", STD 7,
1408                  RFC 793, September 1981.
1409
1410
1411Appendix A., paragraph 1:
1412OLD:
1413
1414    HTTP has been in use since 1990.  The first version, later referred
1415    to as HTTP/0.9, was a simple protocol for hypertext data transfer
1416    across the Internet, using only a single request method (GET) and no
1417    metadata.  HTTP/1.0, as defined by [RFC1945], added a range of
1418    request methods and MIME-like messaging, allowing for metadata to be
1419    transferred and modifiers placed on the request/response semantics.
1420    However, HTTP/1.0 did not sufficiently take into consideration the
1421    effects of hierarchical proxies, caching, the need for persistent
1422    connections, or name-based virtual hosts.  The proliferation of
1423    incompletely-implemented applications calling themselves "HTTP/1.0"
1424    further necessitated a protocol version change in order for two
1425    communicating applications to determine each other's true
1426    capabilities.
1427
1428NEW:
1429
1430    HTTP has been in use since 1990.  The first version, later referred
1431    to as HTTP/0.9, was a simple protocol for hypertext data transfer
1432    across the Internet, using only a single request method (GET) and no
1433    metadata.  HTTP/1.0, as defined by [RFC1945], added a range of
1434    request methods and MIME-like messaging, allowing for metadata to be
1435    transferred and modifiers placed on the request/response semantics.
1436    However, HTTP/1.0 did not sufficiently take into consideration the
1437    effects of hierarchical proxies, caching, the need for persistent
1438    connections, or name-based virtual hosts.  The proliferation of
1439    incompletely implemented applications calling themselves "HTTP/1.0"
1440    further necessitated a protocol version change in order for two
1441    communicating applications to determine each other's true
1442    capabilities.
1443
1444
1445Appendix A., paragraph 7:
1446OLD:
1447
1448 A.1.1.  Multi-homed Web Servers
1449
1450NEW:
1451
1452 A.1.1.  Multihomed Web Servers
1453
1454
1455Section 19.7.1, paragraph 8:
1456OLD:
1457
1458    HTTP's approach to error handling has been explained.  (Section 2.5)
1459
1460NEW:
1461
1462    HTTP's approach to error handling has been explained (Section 2.5).
1463
1464
1465Section 19.7.1, paragraph 9:
1466OLD:
1467
1468    The HTTP-version ABNF production has been clarified to be case-
1469    sensitive.  Additionally, version numbers have been restricted to
1470    single digits, due to the fact that implementations are known to
1471    handle multi-digit version numbers incorrectly.  (Section 2.6)
1472
1473NEW:
1474
1475    The HTTP-version ABNF production has been clarified to be case
1476    sensitive.  Additionally, version numbers have been restricted to
1477    single digits, due to the fact that implementations are known to
1478    handle multi-digit version numbers incorrectly (Section 2.6).
1479
1480
1481Section 19.7.1, paragraph 10:
1482OLD:
1483
1484    Userinfo (i.e., username and password) are now disallowed in HTTP and
1485    HTTPS URIs, because of security issues related to their transmission
1486    on the wire.  (Section 2.7.1)
1487
1488NEW:
1489
1490    Userinfo (i.e., username and password) are now disallowed in HTTP and
1491    HTTPS URIs, because of security issues related to their transmission
1492    on the wire (Section 2.7.1).
1493
1494
1495Section 19.7.1, paragraph 11:
1496OLD:
1497
1498    The HTTPS URI scheme is now defined by this specification;
1499    previously, it was done in Section 2.4 of [RFC2818].  Furthermore, it
1500    implies end-to-end security.  (Section 2.7.2)
1501
1502NEW:
1503
1504    The HTTPS URI scheme is now defined by this specification;
1505    previously, it was defined in Section 2.4 of [RFC2818].  Furthermore,
1506    it implies end-to-end security (Section 2.7.2).
1507
1508
1509Section 19.7.1, paragraph 12:
1510OLD:
1511
1512    HTTP messages can be (and often are) buffered by implementations;
1513    despite it sometimes being available as a stream, HTTP is
1514    fundamentally a message-oriented protocol.  Minimum supported sizes
1515    for various protocol elements have been suggested, to improve
1516    interoperability.  (Section 3)
1517
1518NEW:
1519
1520    HTTP messages can be (and often are) buffered by implementations;
1521    despite it sometimes being available as a stream, HTTP is
1522    fundamentally a message-oriented protocol.  Minimum supported sizes
1523    for various protocol elements have been suggested, to improve
1524    interoperability (Section 3).
1525
1526
1527Section 19.7.1, paragraph 13:
1528OLD:
1529
1530    Invalid whitespace around field-names is now required to be rejected,
1531    because accepting it represents a security vulnerability.  The ABNF
1532    productions defining header fields now only list the field value.
1533    (Section 3.2)
1534
1535NEW:
1536
1537    Invalid whitespace around field-names is now required to be rejected,
1538    because accepting it represents a security vulnerability.  The ABNF
1539    productions defining header fields now only list the field value
1540    (Section 3.2).
1541
1542
1543Section 19.7.1, paragraph 14:
1544OLD:
1545
1546    Rules about implicit linear whitespace between certain grammar
1547    productions have been removed; now whitespace is only allowed where
1548    specifically defined in the ABNF.  (Section 3.2.3)
1549
1550NEW:
1551
1552    Rules about implicit linear whitespace between certain grammar
1553    productions have been removed; now whitespace is only allowed where
1554    specifically defined in the ABNF (Section 3.2.3).
1555
1556
1557Section 19.7.1, paragraph 15:
1558OLD:
1559
1560    Header fields that span multiple lines ("line folding") are
1561    deprecated.  (Section 3.2.4)
1562    The NUL octet is no longer allowed in comment and quoted-string text,
1563    and handling of backslash-escaping in them has been clarified.  The
1564    quoted-pair rule no longer allows escaping control characters other
1565    than HTAB.  Non-ASCII content in header fields and the reason phrase
1566    has been obsoleted and made opaque (the TEXT rule was removed).
1567    (Section 3.2.6)
1568
1569NEW:
1570
1571    Header fields that span multiple lines ("line folding") are
1572    deprecated (Section 3.2.4).
1573 
1574    The NUL octet is no longer allowed in comment and quoted-string text,
1575    and handling of backslash-escaping in them has been clarified.  The
1576    quoted-pair rule no longer allows escaping control characters other
1577    than HTAB.  Non-US-ASCII content in header fields and the reason
1578    phrase has been obsoleted and made opaque (the TEXT rule was removed)
1579    (Section 3.2.6).
1580
1581
1582Section 19.7.1, paragraph 16:
1583OLD:
1584
1585    Bogus "Content-Length" header fields are now required to be handled
1586    as errors by recipients.  (Section 3.3.2)
1587
1588NEW:
1589
1590    Bogus "Content-Length" header fields are now required to be handled
1591    as errors by recipients (Section 3.3.2).
1592
1593
1594Section 19.7.1, paragraph 17:
1595OLD:
1596
1597    The algorithm for determining the message body length has been
1598    clarified to indicate all of the special cases (e.g., driven by
1599    methods or status codes) that affect it, and that new protocol
1600    elements cannot define such special cases.  CONNECT is a new, special
1601    case in determining message body length. "multipart/byteranges" is no
1602    longer a way of determining message body length detection.
1603    (Section 3.3.3)
1604
1605NEW:
1606
1607    The algorithm for determining the message body length has been
1608    clarified to indicate all of the special cases (e.g., driven by
1609    methods or status codes) that affect it, and that new protocol
1610    elements cannot define such special cases.  CONNECT is a new, special
1611    case in determining message body length. "multipart/byteranges" is no
1612    longer a way of determining message body length detection
1613    (Section 3.3.3).
1614
1615
1616Section 19.7.1, paragraph 18:
1617OLD:
1618
1619    The "identity" transfer coding token has been removed.  (Sections 3.3
1620    and 4)
1621
1622NEW:
1623
1624    The "identity" transfer coding token has been removed (Sections 3.3
1625    and 4).
1626
1627
1628Section 19.7.1, paragraph 19:
1629OLD:
1630
1631    Chunk length does not include the count of the octets in the chunk
1632    header and trailer.  Line folding in chunk extensions is disallowed.
1633    (Section 4.1)
1634
1635NEW:
1636
1637    Chunk length does not include the count of the octets in the chunk
1638    header and trailer.  Line folding in chunk extensions is disallowed
1639    (Section 4.1).
1640
1641
1642Section 19.7.1, paragraph 20:
1643OLD:
1644
1645    The meaning of the "deflate" content coding has been clarified.
1646    (Section 4.2.2)
1647
1648NEW:
1649
1650    The meaning of the "deflate" content coding has been clarified
1651    (Section 4.2.2).
1652
1653
1654Section 19.7.1, paragraph 21:
1655OLD:
1656
1657    The segment + query components of RFC 3986 have been used to define
1658    the request-target, instead of abs_path from RFC 1808.  The asterisk-
1659    form of the request-target is only allowed with the OPTIONS method.
1660    (Section 5.3)
1661
1662NEW:
1663
1664    The segment + query components of RFC 3986 have been used to define
1665    the request-target, instead of abs_path from RFC 1808.  The asterisk-
1666    form of the request-target is only allowed with the OPTIONS method
1667    (Section 5.3).
1668
1669
1670Section 19.7.1, paragraph 22:
1671OLD:
1672
1673    The term "Effective Request URI" has been introduced.  (Section 5.5)
1674
1675NEW:
1676
1677    The term "Effective Request URI" has been introduced (Section 5.5).
1678
1679
1680Section 19.7.1, paragraph 23:
1681OLD:
1682
1683    Gateways do not need to generate Via header fields anymore.
1684    (Section 5.7.1)
1685
1686NEW:
1687
1688    Gateways do not need to generate Via header fields anymore
1689    (Section 5.7.1).
1690
1691
1692Section 19.7.1, paragraph 24:
1693OLD:
1694
1695    Exactly when "close" connection options have to be sent has been
1696    clarified.  Also, "hop-by-hop" header fields are required to appear
1697    in the Connection header field; just because they're defined as hop-
1698    by-hop in this specification doesn't exempt them.  (Section 6.1)
1699
1700NEW:
1701
1702    Exactly when "close" connection options have to be sent has been
1703    clarified.  Also, "hop-by-hop" header fields are required to appear
1704    in the Connection header field; just because they're defined as hop-
1705    by-hop in this specification doesn't exempt them (Section 6.1).
1706
1707
1708Section 19.7.1, paragraph 25:
1709OLD:
1710
1711    The limit of two connections per server has been removed.  An
1712    idempotent sequence of requests is no longer required to be retried.
1713    The requirement to retry requests under certain circumstances when
1714    the server prematurely closes the connection has been removed.  Also,
1715    some extraneous requirements about when servers are allowed to close
1716    connections prematurely have been removed.  (Section 6.3)
1717
1718NEW:
1719
1720    The limit of two connections per server has been removed.  An
1721    idempotent sequence of requests is no longer required to be retried.
1722    The requirement to retry requests under certain circumstances when
1723    the server prematurely closes the connection has been removed.  Also,
1724    some extraneous requirements about when servers are allowed to close
1725    connections prematurely have been removed (Section 6.3).
1726
1727
1728Section 19.7.1, paragraph 26:
1729OLD:
1730
1731    The semantics of the Upgrade header field is now defined in responses
1732    other than 101 (this was incorporated from [RFC2817]).  Furthermore,
1733    the ordering in the field value is now significant.  (Section 6.7)
1734
1735NEW:
1736
1737    The semantics of the Upgrade header field is now defined in responses
1738    other than 101 (this was incorporated from [RFC2817]).  Furthermore,
1739    the ordering in the field value is now significant (Section 6.7).
1740
1741
1742Section 19.7.1, paragraph 27:
1743OLD:
1744
1745    Empty list elements in list productions (e.g., a list header field
1746    containing ", ,") have been deprecated.  (Section 7)
1747
1748NEW:
1749
1750    Empty list elements in list productions (e.g., a list header field
1751    containing ", ,") have been deprecated (Section 7).
1752
1753
1754Section 19.7.1, paragraph 28:
1755OLD:
1756
1757    Registration of Transfer Codings now requires IETF Review
1758    (Section 8.4)
1759
1760NEW:
1761
1762    Registration of Transfer Codings now requires IETF Review
1763    (Section 8.4).
1764
1765
1766Section 19.7.1, paragraph 29:
1767OLD:
1768
1769    This specification now defines the Upgrade Token Registry, previously
1770    defined in Section 7.2 of [RFC2817].  (Section 8.6)
1771
1772NEW:
1773
1774    This specification now defines the "HTTP Upgrade Tokens" registry,
1775    previously defined in Section 7.2 of [RFC2817] (Section 8.6).
1776
1777
1778Section 19.7.1, paragraph 30:
1779OLD:
1780
1781    The expectation to support HTTP/0.9 requests has been removed.
1782    (Appendix A)
1783
1784NEW:
1785
1786    The expectation to support HTTP/0.9 requests has been removed
1787    (Appendix A).
1788
1789
1790Section 19.7.1, paragraph 31:
1791OLD:
1792
1793    Issues with the Keep-Alive and Proxy-Connection header fields in
1794    requests are pointed out, with use of the latter being discouraged
1795    altogether.  (Appendix A.1.2)
1796
1797NEW:
1798
1799    Issues with the Keep-Alive and Proxy-Connection header fields in
1800    requests are pointed out, with use of the latter being discouraged
1801    altogether (Appendix A.1.2).
1802
1803
1804Appendix B., paragraph 7:
1805OLD:
1806
1807    URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
1808    Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
1809    Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
1810     ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
1811     comment ] ) ] )
1812
1813NEW:
1814
1815    URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
1816    Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
1817 
1818    Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
1819     ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
1820     comment ] ) ] )
1821
1822
1823Appendix B., paragraph 15:
1824OLD:
1825
1826    partial-URI = relative-part [ "?" query ]
1827    path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
1828    port = <port, defined in [RFC3986], Section 3.2.3>
1829    protocol = protocol-name [ "/" protocol-version ]
1830    protocol-name = token
1831    protocol-version = token
1832    pseudonym = token
1833 
1834    qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
1835     / %x5D-7E ; ']'-'~'
1836     / obs-text
1837    query = <query, defined in [RFC3986], Section 3.4>
1838    quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
1839    quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
1840
1841NEW:
1842
1843    partial-URI = relative-part [ "?" query ]
1844    path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
1845    port = <port, defined in [RFC3986], Section 3.2.3>
1846    protocol = protocol-name [ "/" protocol-version ]
1847    protocol-name = token
1848    protocol-version = token
1849    pseudonym = token
1850    qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
1851     / %x5D-7E ; ']'-'~'
1852     / obs-text
1853    query = <query, defined in [RFC3986], Section 3.4>
1854    quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
1855    quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
1856
1857
1858Appendix B., paragraph 24:
1859OLD:
1860
1861    D
1862       deflate (Coding Format)  38
1863       Delimiters  26
1864       downstream  9
1865
1866NEW:
1867
1868    D
1869       deflate (Coding Format)  38
1870       Delimiters  26
1871       downstream  10
1872
1873
1874Appendix B., paragraph 26:
1875OLD:
1876
1877    G
1878       gateway  10
1879       Grammar
1880          absolute-form  41-42
1881          absolute-path  16
1882          absolute-URI  16
1883          ALPHA  6
1884          asterisk-form  41-42
1885          authority  16
1886          authority-form  41-42
1887          BWS  24
1888          chunk  35
1889          chunk-data  35
1890          chunk-ext  35-36
1891          chunk-ext-name  36
1892          chunk-ext-val  36
1893          chunk-size  35
1894          chunked-body  35-36
1895          comment  27
1896          Connection  51
1897          connection-option  51
1898          Content-Length  30
1899          CR  6
1900          CRLF  6
1901          ctext  27
1902          CTL  6
1903          DIGIT  6
1904          DQUOTE  6
1905          field-content  22
1906          field-name  22, 39
1907          field-value  22
1908          field-vchar  22
1909          fragment  16
1910          header-field  22, 36
1911          HEXDIG  6
1912          Host  43
1913          HTAB  6
1914          HTTP-message  19
1915          HTTP-name  13
1916          http-URI  16
1917          HTTP-version  13
1918          https-URI  18
1919          last-chunk  35
1920          LF  6
1921          message-body  27
1922          method  21
1923          obs-fold  22
1924          obs-text  27
1925          OCTET  6
1926          origin-form  41
1927          OWS  24
1928          partial-URI  16
1929          port  16
1930          protocol-name  47
1931          protocol-version  47
1932          pseudonym  47
1933          qdtext  27
1934          query  16
1935          quoted-pair  27
1936          quoted-string  27
1937          rank  38
1938          reason-phrase  22
1939          received-by  47
1940          received-protocol  47
1941          request-line  21
1942          request-target  41
1943          RWS  24
1944          scheme  16
1945          segment  16
1946          SP  6
1947          start-line  20
1948          status-code  22
1949          status-line  22
1950          t-codings  38
1951          t-ranking  38
1952          tchar  27
1953          TE  38
1954          token  27
1955          Trailer  39
1956          trailer-part  35-36
1957          transfer-coding  35
1958          Transfer-Encoding  28
1959          transfer-extension  35
1960          transfer-parameter  35
1961          Upgrade  56
1962          uri-host  16
1963          URI-reference  16
1964          VCHAR  6
1965          Via  47
1966       gzip (Coding Format)  38
1967
1968NEW:
1969
1970    G
1971       gateway  10
1972       Grammar
1973          absolute-form  41-42
1974          absolute-path  16
1975          absolute-URI  16
1976          ALPHA  6
1977          asterisk-form  41-42
1978          authority  16
1979          authority-form  41-42
1980          BWS  24
1981          chunk  35
1982          chunk-data  35
1983          chunk-ext  35-36
1984          chunk-ext-name  36
1985          chunk-ext-val  36
1986          chunk-size  35
1987          chunked-body  35-36
1988          comment  27
1989          Connection  51
1990          connection-option  51
1991          Content-Length  30
1992          CR  6
1993          CRLF  6
1994          ctext  27
1995          CTL  6
1996          DIGIT  6
1997          DQUOTE  6
1998          field-content  22
1999          field-name  22, 39
2000          field-value  22
2001          field-vchar  22
2002          fragment  16
2003          header-field  22, 36
2004          HEXDIG  6
2005          Host  43
2006          HTAB  6
2007          HTTP-message  19
2008          HTTP-name  14
2009          http-URI  16
2010          HTTP-version  14
2011          https-URI  18
2012          last-chunk  35
2013          LF  6
2014          message-body  27
2015          method  21
2016          obs-fold  22
2017          obs-text  27
2018          OCTET  6
2019          origin-form  41
2020          OWS  24
2021          partial-URI  16
2022          port  16
2023          protocol-name  47
2024          protocol-version  47
2025          pseudonym  47
2026          qdtext  27
2027          query  16
2028          quoted-pair  27
2029          quoted-string  27
2030          rank  38
2031          reason-phrase  22
2032          received-by  47
2033          received-protocol  47
2034          request-line  21
2035          request-target  41
2036          RWS  24
2037          scheme  16
2038          segment  16
2039          SP  6
2040          start-line  20
2041          status-code  22
2042          status-line  22
2043          t-codings  38
2044          t-ranking  38
2045          tchar  27
2046          TE  38
2047          token  27
2048          Trailer  39
2049          trailer-part  35-36
2050          transfer-coding  35
2051          Transfer-Encoding  28
2052          transfer-extension  35
2053          transfer-parameter  35
2054          Upgrade  56
2055          uri-host  16
2056          URI-reference  16
2057          VCHAR  6
2058          Via  47
2059       gzip (Coding Format)  38
2060
2061
2062Appendix B., paragraph 28:
2063OLD:
2064
2065    I
2066       inbound  9
2067       interception proxy  11
2068       intermediary  9
2069
2070NEW:
2071
2072    I
2073       inbound  10
2074       interception proxy  11
2075       intermediary  9
2076
2077
2078Appendix B., paragraph 31:
2079OLD:
2080
2081    O
2082       origin server  7
2083       origin-form (of request-target)  41
2084       outbound  9
2085
2086NEW:
2087
2088    O
2089       origin server  7
2090       origin-form (of request-target)  41
2091       outbound  10
2092
2093
2094Appendix B., paragraph 36:
2095OLD:
2096
2097    U
2098       Upgrade header field  56
2099       upstream  9
2100       URI scheme
2101          http  16
2102          https  18
2103       user agent  7
2104
2105NEW:
2106
2107    U
2108       Upgrade header field  56
2109       upstream  10
2110       URI scheme
2111          http  16
2112          https  18
2113       user agent  7
2114
2115
2116Section 345, paragraph 1:
2117OLD:
2118
2119    EMail: fielding@gbiv.com
2120    URI:   http://roy.gbiv.com/
2121 
2122    Julian F. Reschke (editor)
2123    greenbytes GmbH
2124    Hafenweg 16
2125    Muenster, NW  48155
2126    Germany
2127
2128NEW:
2129
2130    EMail: fielding@gbiv.com
2131    URI:   http://roy.gbiv.com/
2132    Julian F. Reschke (editor)
2133    greenbytes GmbH
2134    Hafenweg 16
2135    Muenster, NW  48155
2136    Germany
2137
Note: See TracBrowser for help on using the repository browser.