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

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

"namespace" (#553)

File size: 76.2 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 namespace 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.2., paragraph 1:
1153OLD:
1154
1155    The HTTP Transfer Coding Registry shall be updated with the
1156    registrations below:
1157
1158NEW:
1159
1160    The "HTTP Transfer Coding Registry" has been updated with the
1161    registrations below:
1162
1163
1164Section 8.5., paragraph 1:
1165OLD:
1166
1167    IANA maintains the registry of HTTP Content Codings at
1168    <http://www.iana.org/assignments/http-parameters>.
1169
1170NEW:
1171
1172    IANA maintains the "HTTP Content Coding Registry" at
1173    <http://www.iana.org/assignments/http-parameters>.
1174
1175
1176Section 8.5., paragraph 2:
1177OLD:
1178
1179    The HTTP Content Codings Registry shall be updated with the
1180    registrations below:
1181
1182NEW:
1183
1184    The "HTTP Content Codings Registry" has been updated with the
1185    registrations below:
1186
1187
1188Section 8.6., paragraph 1:
1189OLD:
1190
1191    The HTTP Upgrade Token Registry defines the namespace for protocol-
1192    name tokens used to identify protocols in the Upgrade header field.
1193    The registry is maintained at
1194    <http://www.iana.org/assignments/http-upgrade-tokens>.
1195
1196NEW:
1197
1198    The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
1199    defines the namespace for protocol-name tokens used to identify
1200    protocols in the Upgrade header field.  The registry is maintained at
1201    <http://www.iana.org/assignments/http-upgrade-tokens>.
1202
1203
1204Section 8.6.2., paragraph 1:
1205OLD:
1206
1207    The "HTTP" entry in the HTTP Upgrade Token Registry shall be updated
1208    with the registration below:
1209
1210NEW:
1211
1212    The "HTTP" entry in the "HTTP Upgrade Token" registry shall be
1213    updated with the registration below:
1214
1215
1216Section 9.1., paragraph 3:
1217OLD:
1218
1219    When a registered name is used in the authority component, the "http"
1220    URI scheme (Section 2.7.1) relies on the user's local name resolution
1221    service to determine where it can find authoritative responses.  This
1222    means that any attack on a user's network host table, cached names,
1223    or name resolution libraries becomes an avenue for attack on
1224    establishing authority.  Likewise, the user's choice of server for
1225    Domain Name Service (DNS), and the hierarchy of servers from which it
1226    obtains resolution results, could impact the authenticity of address
1227    mappings; DNS Security Extensions (DNSSEC, [RFC4033]) are one way to
1228    improve authenticity.
1229
1230NEW:
1231
1232    When a registered name is used in the authority component, the "http"
1233    URI scheme (Section 2.7.1) relies on the user's local name resolution
1234    service to determine where it can find authoritative responses.  This
1235    means that any attack on a user's network host table, cached names,
1236    or name resolution libraries becomes an avenue for attack on
1237    establishing authority.  Likewise, the user's choice of server for
1238    Domain Name Service (DNS), and the hierarchy of servers from which it
1239    obtains resolution results, could impact the authenticity of address
1240    mappings; DNS Security Extensions (DNSSEC) ([RFC4033]) is one way to
1241    improve authenticity.
1242
1243
1244Section 9.2., paragraph 1:
1245OLD:
1246
1247    By their very nature, HTTP intermediaries are men-in-the-middle, and
1248    thus represent an opportunity for man-in-the-middle attacks.
1249    Compromise of the systems on which the intermediaries run can result
1250    in serious security and privacy problems.  Intermediaries might have
1251    access to security-related information, personal information about
1252    individual users and organizations, and proprietary information
1253    belonging to users and content providers.  A compromised
1254    intermediary, or an intermediary implemented or configured without
1255    regard to security and privacy considerations, might be used in the
1256    commission of a wide range of potential attacks.
1257
1258NEW:
1259
1260    By their very nature, HTTP intermediaries are men in the middle and,
1261    thus, represent an opportunity for man-in-the-middle attacks.
1262    Compromise of the systems on which the intermediaries run can result
1263    in serious security and privacy problems.  Intermediaries might have
1264    access to security-related information, personal information about
1265    individual users and organizations, and proprietary information
1266    belonging to users and content providers.  A compromised
1267    intermediary, or an intermediary implemented or configured without
1268    regard to security and privacy considerations, might be used in the
1269    commission of a wide range of potential attacks.
1270
1271
1272Section 9.6., paragraph 2:
1273OLD:
1274
1275    User agents are encouraged to implement configurable means for
1276    detecting and reporting failures of message integrity such that those
1277    means can be enabled within environments for which integrity is
1278    necessary.  For example, a browser being used to view medical history
1279    or drug interaction information needs to indicate to the user when
1280    such information is detected by the protocol to be incomplete,
1281    expired, or corrupted during transfer.  Such mechanisms might be
1282    selectively enabled via user agent extensions or the presence of
1283    message integrity metadata in a response.  At a minimum, user agents
1284    ought to provide some indication that allows a user to distinguish
1285    between a complete and incomplete response message (Section 3.4) when
1286    such verification is desired.
1287
1288NEW:
1289
1290    User agents are encouraged to implement configurable means for
1291    detecting and reporting failures of message integrity such that those
1292    means can be enabled within environments for which integrity is
1293    necessary.  For example, a browser being used to view medical history
1294    or drug interaction information needs to indicate to the user when
1295    such information is detected by the protocol to be incomplete,
1296    expired, or corrupted during transfer.  Such mechanisms might be
1297    selectively enabled via user-agent extensions or the presence of
1298    message integrity metadata in a response.  At a minimum, user agents
1299    ought to provide some indication that allows a user to distinguish
1300    between a complete and incomplete response message (Section 3.4) when
1301    such verification is desired.
1302
1303
1304Section 11.1., paragraph 1:
1305OLD:
1306
1307    [RFC0793]     Postel, J., "Transmission Control Protocol", STD 7,
1308                  RFC 793, September 1981.
1309 
1310    [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
1311                  Format Specification version 3.3", RFC 1950, May 1996.
1312
1313NEW:
1314
1315    [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
1316                  Format Specification version 3.3", RFC 1950, May 1996.
1317
1318
1319Section 11.1., paragraph 7:
1320OLD:
1321
1322    [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1323                  Transfer Protocol (HTTP/1.1): Semantics and Content",
1324                  draft-ietf-httpbis-p2-semantics-latest (work in
1325                  progress), May 2014.
1326
1327NEW:
1328
1329    [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1330                  Transfer Protocol (HTTP/1.1): Semantics and Content",
1331                  RFC 7231, May 2014.
1332
1333
1334Section 11.1., paragraph 8:
1335OLD:
1336
1337    [RFC7232]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1338                  Transfer Protocol (HTTP/1.1): Conditional Requests",
1339                  draft-ietf-httpbis-p4-conditional-latest (work in
1340                  progress), May 2014.
1341
1342NEW:
1343
1344    [RFC7232]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1345                  Transfer Protocol (HTTP/1.1): Conditional Requests",
1346                  RFC 7232, May 2014.
1347
1348
1349Section 11.1., paragraph 9:
1350OLD:
1351
1352    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1353                  "Hypertext Transfer Protocol (HTTP/1.1): Range
1354                  Requests", draft-ietf-httpbis-p5-range-latest (work in
1355                  progress), May 2014.
1356
1357NEW:
1358
1359    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1360                  "Hypertext Transfer Protocol (HTTP/1.1): Range
1361                  Requests", RFC 7233, May 2014.
1362
1363
1364Section 11.1., paragraph 10:
1365OLD:
1366
1367    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1368                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1369                  draft-ietf-httpbis-p6-cache-latest (work in progress),
1370                  May 2014.
1371
1372NEW:
1373
1374    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1375                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1376                  RFC 7234, May 2014.
1377
1378
1379Section 11.1., paragraph 11:
1380OLD:
1381
1382    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1383                  Transfer Protocol (HTTP/1.1): Authentication",
1384                  draft-ietf-httpbis-p7-auth-latest (work in progress),
1385                  May 2014.
1386
1387NEW:
1388
1389    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1390                  Transfer Protocol (HTTP/1.1): Authentication",
1391                  RFC 7235, May 2014.
1392 
1393    [RFC793]      Postel, J., "Transmission Control Protocol", STD 7,
1394                  RFC 793, September 1981.
1395
1396
1397Appendix A., paragraph 1:
1398OLD:
1399
1400    HTTP has been in use since 1990.  The first version, later referred
1401    to as HTTP/0.9, was a simple protocol for hypertext data transfer
1402    across the Internet, using only a single request method (GET) and no
1403    metadata.  HTTP/1.0, as defined by [RFC1945], added a range of
1404    request methods and MIME-like messaging, allowing for metadata to be
1405    transferred and modifiers placed on the request/response semantics.
1406    However, HTTP/1.0 did not sufficiently take into consideration the
1407    effects of hierarchical proxies, caching, the need for persistent
1408    connections, or name-based virtual hosts.  The proliferation of
1409    incompletely-implemented applications calling themselves "HTTP/1.0"
1410    further necessitated a protocol version change in order for two
1411    communicating applications to determine each other's true
1412    capabilities.
1413
1414NEW:
1415
1416    HTTP has been in use since 1990.  The first version, later referred
1417    to as HTTP/0.9, was a simple protocol for hypertext data transfer
1418    across the Internet, using only a single request method (GET) and no
1419    metadata.  HTTP/1.0, as defined by [RFC1945], added a range of
1420    request methods and MIME-like messaging, allowing for metadata to be
1421    transferred and modifiers placed on the request/response semantics.
1422    However, HTTP/1.0 did not sufficiently take into consideration the
1423    effects of hierarchical proxies, caching, the need for persistent
1424    connections, or name-based virtual hosts.  The proliferation of
1425    incompletely implemented applications calling themselves "HTTP/1.0"
1426    further necessitated a protocol version change in order for two
1427    communicating applications to determine each other's true
1428    capabilities.
1429
1430
1431Appendix A., paragraph 7:
1432OLD:
1433
1434 A.1.1.  Multi-homed Web Servers
1435
1436NEW:
1437
1438 A.1.1.  Multihomed Web Servers
1439
1440
1441Section 19.7.1, paragraph 8:
1442OLD:
1443
1444    HTTP's approach to error handling has been explained.  (Section 2.5)
1445
1446NEW:
1447
1448    HTTP's approach to error handling has been explained (Section 2.5).
1449
1450
1451Section 19.7.1, paragraph 9:
1452OLD:
1453
1454    The HTTP-version ABNF production has been clarified to be case-
1455    sensitive.  Additionally, version numbers have been restricted to
1456    single digits, due to the fact that implementations are known to
1457    handle multi-digit version numbers incorrectly.  (Section 2.6)
1458
1459NEW:
1460
1461    The HTTP-version ABNF production has been clarified to be case
1462    sensitive.  Additionally, version numbers have been restricted to
1463    single digits, due to the fact that implementations are known to
1464    handle multi-digit version numbers incorrectly (Section 2.6).
1465
1466
1467Section 19.7.1, paragraph 10:
1468OLD:
1469
1470    Userinfo (i.e., username and password) are now disallowed in HTTP and
1471    HTTPS URIs, because of security issues related to their transmission
1472    on the wire.  (Section 2.7.1)
1473
1474NEW:
1475
1476    Userinfo (i.e., username and password) are now disallowed in HTTP and
1477    HTTPS URIs, because of security issues related to their transmission
1478    on the wire (Section 2.7.1).
1479
1480
1481Section 19.7.1, paragraph 11:
1482OLD:
1483
1484    The HTTPS URI scheme is now defined by this specification;
1485    previously, it was done in Section 2.4 of [RFC2818].  Furthermore, it
1486    implies end-to-end security.  (Section 2.7.2)
1487
1488NEW:
1489
1490    The HTTPS URI scheme is now defined by this specification;
1491    previously, it was defined in Section 2.4 of [RFC2818].  Furthermore,
1492    it implies end-to-end security (Section 2.7.2).
1493
1494
1495Section 19.7.1, paragraph 12:
1496OLD:
1497
1498    HTTP messages can be (and often are) buffered by implementations;
1499    despite it sometimes being available as a stream, HTTP is
1500    fundamentally a message-oriented protocol.  Minimum supported sizes
1501    for various protocol elements have been suggested, to improve
1502    interoperability.  (Section 3)
1503
1504NEW:
1505
1506    HTTP messages can be (and often are) buffered by implementations;
1507    despite it sometimes being available as a stream, HTTP is
1508    fundamentally a message-oriented protocol.  Minimum supported sizes
1509    for various protocol elements have been suggested, to improve
1510    interoperability (Section 3).
1511
1512
1513Section 19.7.1, paragraph 13:
1514OLD:
1515
1516    Invalid whitespace around field-names is now required to be rejected,
1517    because accepting it represents a security vulnerability.  The ABNF
1518    productions defining header fields now only list the field value.
1519    (Section 3.2)
1520
1521NEW:
1522
1523    Invalid whitespace around field-names is now required to be rejected,
1524    because accepting it represents a security vulnerability.  The ABNF
1525    productions defining header fields now only list the field value
1526    (Section 3.2).
1527
1528
1529Section 19.7.1, paragraph 14:
1530OLD:
1531
1532    Rules about implicit linear whitespace between certain grammar
1533    productions have been removed; now whitespace is only allowed where
1534    specifically defined in the ABNF.  (Section 3.2.3)
1535
1536NEW:
1537
1538    Rules about implicit linear whitespace between certain grammar
1539    productions have been removed; now whitespace is only allowed where
1540    specifically defined in the ABNF (Section 3.2.3).
1541
1542
1543Section 19.7.1, paragraph 15:
1544OLD:
1545
1546    Header fields that span multiple lines ("line folding") are
1547    deprecated.  (Section 3.2.4)
1548    The NUL octet is no longer allowed in comment and quoted-string text,
1549    and handling of backslash-escaping in them has been clarified.  The
1550    quoted-pair rule no longer allows escaping control characters other
1551    than HTAB.  Non-ASCII content in header fields and the reason phrase
1552    has been obsoleted and made opaque (the TEXT rule was removed).
1553    (Section 3.2.6)
1554
1555NEW:
1556
1557    Header fields that span multiple lines ("line folding") are
1558    deprecated (Section 3.2.4).
1559 
1560    The NUL octet is no longer allowed in comment and quoted-string text,
1561    and handling of backslash-escaping in them has been clarified.  The
1562    quoted-pair rule no longer allows escaping control characters other
1563    than HTAB.  Non-US-ASCII content in header fields and the reason
1564    phrase has been obsoleted and made opaque (the TEXT rule was removed)
1565    (Section 3.2.6).
1566
1567
1568Section 19.7.1, paragraph 16:
1569OLD:
1570
1571    Bogus "Content-Length" header fields are now required to be handled
1572    as errors by recipients.  (Section 3.3.2)
1573
1574NEW:
1575
1576    Bogus "Content-Length" header fields are now required to be handled
1577    as errors by recipients (Section 3.3.2).
1578
1579
1580Section 19.7.1, paragraph 17:
1581OLD:
1582
1583    The algorithm for determining the message body length has been
1584    clarified to indicate all of the special cases (e.g., driven by
1585    methods or status codes) that affect it, and that new protocol
1586    elements cannot define such special cases.  CONNECT is a new, special
1587    case in determining message body length. "multipart/byteranges" is no
1588    longer a way of determining message body length detection.
1589    (Section 3.3.3)
1590
1591NEW:
1592
1593    The algorithm for determining the message body length has been
1594    clarified to indicate all of the special cases (e.g., driven by
1595    methods or status codes) that affect it, and that new protocol
1596    elements cannot define such special cases.  CONNECT is a new, special
1597    case in determining message body length. "multipart/byteranges" is no
1598    longer a way of determining message body length detection
1599    (Section 3.3.3).
1600
1601
1602Section 19.7.1, paragraph 18:
1603OLD:
1604
1605    The "identity" transfer coding token has been removed.  (Sections 3.3
1606    and 4)
1607
1608NEW:
1609
1610    The "identity" transfer coding token has been removed (Sections 3.3
1611    and 4).
1612
1613
1614Section 19.7.1, paragraph 19:
1615OLD:
1616
1617    Chunk length does not include the count of the octets in the chunk
1618    header and trailer.  Line folding in chunk extensions is disallowed.
1619    (Section 4.1)
1620
1621NEW:
1622
1623    Chunk length does not include the count of the octets in the chunk
1624    header and trailer.  Line folding in chunk extensions is disallowed
1625    (Section 4.1).
1626
1627
1628Section 19.7.1, paragraph 20:
1629OLD:
1630
1631    The meaning of the "deflate" content coding has been clarified.
1632    (Section 4.2.2)
1633
1634NEW:
1635
1636    The meaning of the "deflate" content coding has been clarified
1637    (Section 4.2.2).
1638
1639
1640Section 19.7.1, paragraph 21:
1641OLD:
1642
1643    The segment + query components of RFC 3986 have been used to define
1644    the request-target, instead of abs_path from RFC 1808.  The asterisk-
1645    form of the request-target is only allowed with the OPTIONS method.
1646    (Section 5.3)
1647
1648NEW:
1649
1650    The segment + query components of RFC 3986 have been used to define
1651    the request-target, instead of abs_path from RFC 1808.  The asterisk-
1652    form of the request-target is only allowed with the OPTIONS method
1653    (Section 5.3).
1654
1655
1656Section 19.7.1, paragraph 22:
1657OLD:
1658
1659    The term "Effective Request URI" has been introduced.  (Section 5.5)
1660
1661NEW:
1662
1663    The term "Effective Request URI" has been introduced (Section 5.5).
1664
1665
1666Section 19.7.1, paragraph 23:
1667OLD:
1668
1669    Gateways do not need to generate Via header fields anymore.
1670    (Section 5.7.1)
1671
1672NEW:
1673
1674    Gateways do not need to generate Via header fields anymore
1675    (Section 5.7.1).
1676
1677
1678Section 19.7.1, paragraph 24:
1679OLD:
1680
1681    Exactly when "close" connection options have to be sent has been
1682    clarified.  Also, "hop-by-hop" header fields are required to appear
1683    in the Connection header field; just because they're defined as hop-
1684    by-hop in this specification doesn't exempt them.  (Section 6.1)
1685
1686NEW:
1687
1688    Exactly when "close" connection options have to be sent has been
1689    clarified.  Also, "hop-by-hop" header fields are required to appear
1690    in the Connection header field; just because they're defined as hop-
1691    by-hop in this specification doesn't exempt them (Section 6.1).
1692
1693
1694Section 19.7.1, paragraph 25:
1695OLD:
1696
1697    The limit of two connections per server has been removed.  An
1698    idempotent sequence of requests is no longer required to be retried.
1699    The requirement to retry requests under certain circumstances when
1700    the server prematurely closes the connection has been removed.  Also,
1701    some extraneous requirements about when servers are allowed to close
1702    connections prematurely have been removed.  (Section 6.3)
1703
1704NEW:
1705
1706    The limit of two connections per server has been removed.  An
1707    idempotent sequence of requests is no longer required to be retried.
1708    The requirement to retry requests under certain circumstances when
1709    the server prematurely closes the connection has been removed.  Also,
1710    some extraneous requirements about when servers are allowed to close
1711    connections prematurely have been removed (Section 6.3).
1712
1713
1714Section 19.7.1, paragraph 26:
1715OLD:
1716
1717    The semantics of the Upgrade header field is now defined in responses
1718    other than 101 (this was incorporated from [RFC2817]).  Furthermore,
1719    the ordering in the field value is now significant.  (Section 6.7)
1720
1721NEW:
1722
1723    The semantics of the Upgrade header field is now defined in responses
1724    other than 101 (this was incorporated from [RFC2817]).  Furthermore,
1725    the ordering in the field value is now significant (Section 6.7).
1726
1727
1728Section 19.7.1, paragraph 27:
1729OLD:
1730
1731    Empty list elements in list productions (e.g., a list header field
1732    containing ", ,") have been deprecated.  (Section 7)
1733
1734NEW:
1735
1736    Empty list elements in list productions (e.g., a list header field
1737    containing ", ,") have been deprecated (Section 7).
1738
1739
1740Section 19.7.1, paragraph 28:
1741OLD:
1742
1743    Registration of Transfer Codings now requires IETF Review
1744    (Section 8.4)
1745
1746NEW:
1747
1748    Registration of Transfer Codings now requires IETF Review
1749    (Section 8.4).
1750
1751
1752Section 19.7.1, paragraph 29:
1753OLD:
1754
1755    This specification now defines the Upgrade Token Registry, previously
1756    defined in Section 7.2 of [RFC2817].  (Section 8.6)
1757
1758NEW:
1759
1760    This specification now defines the "HTTP Upgrade Tokens" registry,
1761    previously defined in Section 7.2 of [RFC2817] (Section 8.6).
1762
1763
1764Section 19.7.1, paragraph 30:
1765OLD:
1766
1767    The expectation to support HTTP/0.9 requests has been removed.
1768    (Appendix A)
1769
1770NEW:
1771
1772    The expectation to support HTTP/0.9 requests has been removed
1773    (Appendix A).
1774
1775
1776Section 19.7.1, paragraph 31:
1777OLD:
1778
1779    Issues with the Keep-Alive and Proxy-Connection header fields in
1780    requests are pointed out, with use of the latter being discouraged
1781    altogether.  (Appendix A.1.2)
1782
1783NEW:
1784
1785    Issues with the Keep-Alive and Proxy-Connection header fields in
1786    requests are pointed out, with use of the latter being discouraged
1787    altogether (Appendix A.1.2).
1788
1789
1790Appendix B., paragraph 7:
1791OLD:
1792
1793    URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
1794    Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
1795    Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
1796     ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
1797     comment ] ) ] )
1798
1799NEW:
1800
1801    URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
1802    Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
1803 
1804    Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
1805     ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
1806     comment ] ) ] )
1807
1808
1809Appendix B., paragraph 15:
1810OLD:
1811
1812    partial-URI = relative-part [ "?" query ]
1813    path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
1814    port = <port, defined in [RFC3986], Section 3.2.3>
1815    protocol = protocol-name [ "/" protocol-version ]
1816    protocol-name = token
1817    protocol-version = token
1818    pseudonym = token
1819 
1820    qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
1821     / %x5D-7E ; ']'-'~'
1822     / obs-text
1823    query = <query, defined in [RFC3986], Section 3.4>
1824    quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
1825    quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
1826
1827NEW:
1828
1829    partial-URI = relative-part [ "?" query ]
1830    path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
1831    port = <port, defined in [RFC3986], Section 3.2.3>
1832    protocol = protocol-name [ "/" protocol-version ]
1833    protocol-name = token
1834    protocol-version = token
1835    pseudonym = token
1836    qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
1837     / %x5D-7E ; ']'-'~'
1838     / obs-text
1839    query = <query, defined in [RFC3986], Section 3.4>
1840    quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
1841    quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
1842
1843
1844Appendix B., paragraph 24:
1845OLD:
1846
1847    D
1848       deflate (Coding Format)  38
1849       Delimiters  26
1850       downstream  9
1851
1852NEW:
1853
1854    D
1855       deflate (Coding Format)  38
1856       Delimiters  26
1857       downstream  10
1858
1859
1860Appendix B., paragraph 26:
1861OLD:
1862
1863    G
1864       gateway  10
1865       Grammar
1866          absolute-form  41-42
1867          absolute-path  16
1868          absolute-URI  16
1869          ALPHA  6
1870          asterisk-form  41-42
1871          authority  16
1872          authority-form  41-42
1873          BWS  24
1874          chunk  35
1875          chunk-data  35
1876          chunk-ext  35-36
1877          chunk-ext-name  36
1878          chunk-ext-val  36
1879          chunk-size  35
1880          chunked-body  35-36
1881          comment  27
1882          Connection  51
1883          connection-option  51
1884          Content-Length  30
1885          CR  6
1886          CRLF  6
1887          ctext  27
1888          CTL  6
1889          DIGIT  6
1890          DQUOTE  6
1891          field-content  22
1892          field-name  22, 39
1893          field-value  22
1894          field-vchar  22
1895          fragment  16
1896          header-field  22, 36
1897          HEXDIG  6
1898          Host  43
1899          HTAB  6
1900          HTTP-message  19
1901          HTTP-name  13
1902          http-URI  16
1903          HTTP-version  13
1904          https-URI  18
1905          last-chunk  35
1906          LF  6
1907          message-body  27
1908          method  21
1909          obs-fold  22
1910          obs-text  27
1911          OCTET  6
1912          origin-form  41
1913          OWS  24
1914          partial-URI  16
1915          port  16
1916          protocol-name  47
1917          protocol-version  47
1918          pseudonym  47
1919          qdtext  27
1920          query  16
1921          quoted-pair  27
1922          quoted-string  27
1923          rank  38
1924          reason-phrase  22
1925          received-by  47
1926          received-protocol  47
1927          request-line  21
1928          request-target  41
1929          RWS  24
1930          scheme  16
1931          segment  16
1932          SP  6
1933          start-line  20
1934          status-code  22
1935          status-line  22
1936          t-codings  38
1937          t-ranking  38
1938          tchar  27
1939          TE  38
1940          token  27
1941          Trailer  39
1942          trailer-part  35-36
1943          transfer-coding  35
1944          Transfer-Encoding  28
1945          transfer-extension  35
1946          transfer-parameter  35
1947          Upgrade  56
1948          uri-host  16
1949          URI-reference  16
1950          VCHAR  6
1951          Via  47
1952       gzip (Coding Format)  38
1953
1954NEW:
1955
1956    G
1957       gateway  10
1958       Grammar
1959          absolute-form  41-42
1960          absolute-path  16
1961          absolute-URI  16
1962          ALPHA  6
1963          asterisk-form  41-42
1964          authority  16
1965          authority-form  41-42
1966          BWS  24
1967          chunk  35
1968          chunk-data  35
1969          chunk-ext  35-36
1970          chunk-ext-name  36
1971          chunk-ext-val  36
1972          chunk-size  35
1973          chunked-body  35-36
1974          comment  27
1975          Connection  51
1976          connection-option  51
1977          Content-Length  30
1978          CR  6
1979          CRLF  6
1980          ctext  27
1981          CTL  6
1982          DIGIT  6
1983          DQUOTE  6
1984          field-content  22
1985          field-name  22, 39
1986          field-value  22
1987          field-vchar  22
1988          fragment  16
1989          header-field  22, 36
1990          HEXDIG  6
1991          Host  43
1992          HTAB  6
1993          HTTP-message  19
1994          HTTP-name  14
1995          http-URI  16
1996          HTTP-version  14
1997          https-URI  18
1998          last-chunk  35
1999          LF  6
2000          message-body  27
2001          method  21
2002          obs-fold  22
2003          obs-text  27
2004          OCTET  6
2005          origin-form  41
2006          OWS  24
2007          partial-URI  16
2008          port  16
2009          protocol-name  47
2010          protocol-version  47
2011          pseudonym  47
2012          qdtext  27
2013          query  16
2014          quoted-pair  27
2015          quoted-string  27
2016          rank  38
2017          reason-phrase  22
2018          received-by  47
2019          received-protocol  47
2020          request-line  21
2021          request-target  41
2022          RWS  24
2023          scheme  16
2024          segment  16
2025          SP  6
2026          start-line  20
2027          status-code  22
2028          status-line  22
2029          t-codings  38
2030          t-ranking  38
2031          tchar  27
2032          TE  38
2033          token  27
2034          Trailer  39
2035          trailer-part  35-36
2036          transfer-coding  35
2037          Transfer-Encoding  28
2038          transfer-extension  35
2039          transfer-parameter  35
2040          Upgrade  56
2041          uri-host  16
2042          URI-reference  16
2043          VCHAR  6
2044          Via  47
2045       gzip (Coding Format)  38
2046
2047
2048Appendix B., paragraph 28:
2049OLD:
2050
2051    I
2052       inbound  9
2053       interception proxy  11
2054       intermediary  9
2055
2056NEW:
2057
2058    I
2059       inbound  10
2060       interception proxy  11
2061       intermediary  9
2062
2063
2064Appendix B., paragraph 31:
2065OLD:
2066
2067    O
2068       origin server  7
2069       origin-form (of request-target)  41
2070       outbound  9
2071
2072NEW:
2073
2074    O
2075       origin server  7
2076       origin-form (of request-target)  41
2077       outbound  10
2078
2079
2080Appendix B., paragraph 36:
2081OLD:
2082
2083    U
2084       Upgrade header field  56
2085       upstream  9
2086       URI scheme
2087          http  16
2088          https  18
2089       user agent  7
2090
2091NEW:
2092
2093    U
2094       Upgrade header field  56
2095       upstream  10
2096       URI scheme
2097          http  16
2098          https  18
2099       user agent  7
2100
2101
2102Section 345, paragraph 1:
2103OLD:
2104
2105    EMail: fielding@gbiv.com
2106    URI:   http://roy.gbiv.com/
2107 
2108    Julian F. Reschke (editor)
2109    greenbytes GmbH
2110    Hafenweg 16
2111    Muenster, NW  48155
2112    Germany
2113
2114NEW:
2115
2116    EMail: fielding@gbiv.com
2117    URI:   http://roy.gbiv.com/
2118    Julian F. Reschke (editor)
2119    greenbytes GmbH
2120    Hafenweg 16
2121    Muenster, NW  48155
2122    Germany
2123
Note: See TracBrowser for help on using the repository browser.