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

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

mainly grammatical fixes (#553)

File size: 77.4 KB
Line 
1
2INTRODUCTION, paragraph 1:
3OLD:
4
5 HTTPbis Working Group                                   R. Fielding, Ed.
6 Internet-Draft                                                     Adobe
7 Obsoletes: 2145, 2616                                    J. Reschke, Ed.
8 (if approved)                                                 greenbytes
9 Updates: 2817, 2818 (if approved)                            May 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 ISO-
690    8859-1 [ISO-8859-1] charset, supporting other charsets only through
691    use of [RFC2047] encoding.  In practice, most HTTP header field
692    values use only a subset of the US-ASCII charset [USASCII].  Newly
693    defined header fields SHOULD limit their field values to US-ASCII
694    octets.  A recipient SHOULD treat other octets in field content (obs-
695    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 4.2.3., paragraph 1:
743OLD:
744
745    The "gzip" coding is an LZ77 coding with a 32 bit CRC that is
746    commonly produced by the gzip file compression program [RFC1952].  A
747    recipient SHOULD consider "x-gzip" to be equivalent to "gzip".
748
749NEW:
750
751    The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy
752    Check (CRC) that is commonly produced by the gzip file compression
753    program [RFC1952].  A recipient SHOULD consider "x-gzip" to be
754    equivalent to "gzip".
755
756
757Section 5.7.2., paragraph 6:
758OLD:
759
760    A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of
761    a message that contains a no-transform cache-control directive
762    (Section 5.2 of [RFC7234]).
763
764NEW:
765
766    A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of
767    a message that contains a no-transform Cache-Control directive
768    (Section 5.2 of [RFC7234]).
769
770
771Section 200, paragraph 0:
772OLD:
773
774    A proxy MAY transform the payload of a message that does not contain
775    a no-transform cache-control directive.  A proxy that transforms a
776    payload MUST add a Warning header field with the warn-code of 214
777    ("Transformation Applied") if one is not already in the message (see
778    Section 5.5 of [RFC7234]).  A proxy that transforms the payload of a
779    200 (OK) response can further inform downstream recipients that a
780    transformation has been applied by changing the response status code
781    to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).
782
783NEW:
784
785    A proxy MAY transform the payload of a message that does not contain
786    a no-transform Cache-Control directive.  A proxy that transforms a
787    payload MUST add a Warning header field with the warn-code of 214
788    ("Transformation Applied") if one is not already in the message (see
789    Section 5.5 of [RFC7234]).  A proxy that transforms the payload of a
790    200 (OK) response can further inform downstream recipients that a
791    transformation has been applied by changing the response status code
792    to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).
793
794
795Section 6., paragraph 1:
796OLD:
797
798    HTTP messaging is independent of the underlying transport or session-
799    layer connection protocol(s).  HTTP only presumes a reliable
800    transport with in-order delivery of requests and the corresponding
801    in-order delivery of responses.  The mapping of HTTP request and
802    response structures onto the data units of an underlying transport
803    protocol is outside the scope of this specification.
804
805NEW:
806
807    HTTP messaging is independent of the underlying transport- or
808    session-layer connection protocol(s).  HTTP only presumes a reliable
809    transport with in-order delivery of requests and the corresponding
810    in-order delivery of responses.  The mapping of HTTP request and
811    response structures onto the data units of an underlying transport
812    protocol is outside the scope of this specification.
813
814
815Section 6.1., paragraph 6:
816OLD:
817
818    Connection options are case-insensitive.
819
820NEW:
821
822    Connection options are case insensitive.
823
824
825Section 6.2., paragraph 1:
826OLD:
827
828    It is beyond the scope of this specification to describe how
829    connections are established via various transport or session-layer
830    protocols.  Each connection applies to only one transport link.
831
832NEW:
833
834    It is beyond the scope of this specification to describe how
835    connections are established via various transport- or session-layer
836    protocols.  Each connection applies to only one transport link.
837
838
839Section 6.3., paragraph 1:
840OLD:
841
842    HTTP/1.1 defaults to the use of "persistent connections", allowing
843    multiple requests and responses to be carried over a single
844    connection.  The "close" connection-option is used to signal that a
845    connection will not persist after the current request/response.  HTTP
846    implementations SHOULD support persistent connections.
847
848NEW:
849
850    HTTP/1.1 defaults to the use of "persistent connections", allowing
851    multiple requests and responses to be carried over a single
852    connection.  The "close" connection option is used to signal that a
853    connection will not persist after the current request/response.  HTTP
854    implementations SHOULD support persistent connections.
855
856
857Section 6.3., paragraph 3:
858OLD:
859
860    o  If the close connection option is present, the connection will not
861       persist after the current response; else,
862
863NEW:
864
865    o  If the "close" connection option is present, the connection will
866       not persist after the current response; else,
867
868
869Section 6.3., paragraph 7:
870OLD:
871
872    A client MAY send additional requests on a persistent connection
873    until it sends or receives a close connection option or receives an
874    HTTP/1.0 response without a "keep-alive" connection option.
875
876NEW:
877
878    A client MAY send additional requests on a persistent connection
879    until it sends or receives a "close" connection option or receives an
880    HTTP/1.0 response without a "keep-alive" connection option.
881
882
883Section 6.5., paragraph 4:
884OLD:
885
886    A server SHOULD sustain persistent connections, when possible, and
887    allow the underlying transport's flow control mechanisms to resolve
888    temporary overloads, rather than terminate connections with the
889    expectation that clients will retry.  The latter technique can
890    exacerbate network congestion.
891
892NEW:
893
894    A server SHOULD sustain persistent connections, when possible, and
895    allow the underlying transport's flow-control mechanisms to resolve
896    temporary overloads, rather than terminate connections with the
897    expectation that clients will retry.  The latter technique can
898    exacerbate network congestion.
899
900
901Section 6.5., paragraph 6:
902OLD:
903
904 6.6.  Tear-down
905
906NEW:
907
908 6.6.  Teardown
909
910
911Section 6.5., paragraph 8:
912OLD:
913
914    A client that sends a close connection option MUST NOT send further
915    requests on that connection (after the one containing close) and MUST
916    close the connection after reading the final response message
917    corresponding to this request.
918
919NEW:
920
921    A client that sends a "close" connection option MUST NOT send further
922    requests on that connection (after the one containing close) and MUST
923    close the connection after reading the final response message
924    corresponding to this request.
925
926
927Section 6.5., paragraph 9:
928OLD:
929
930    A server that receives a close connection option MUST initiate a
931    close of the connection (see below) after it sends the final response
932    to the request that contained close.  The server SHOULD send a close
933    connection option in its final response on that connection.  The
934    server MUST NOT process any further requests received on that
935    connection.
936
937NEW:
938
939    A server that receives a "close" connection option MUST initiate a
940    close of the connection (see below) after it sends the final response
941    to the request that contained close.  The server SHOULD send a close
942    connection option in its final response on that connection.  The
943    server MUST NOT process any further requests received on that
944    connection.
945
946
947Section 6.5., paragraph 10:
948OLD:
949
950    A server that sends a close connection option MUST initiate a close
951    of the connection (see below) after it sends the response containing
952    close.  The server MUST NOT process any further requests received on
953    that connection.
954
955NEW:
956
957    A server that sends a "close" connection option MUST initiate a close
958    of the connection (see below) after it sends the response containing
959    close.  The server MUST NOT process any further requests received on
960    that connection.
961
962
963Section 6.5., paragraph 11:
964OLD:
965
966    A client that receives a close connection option MUST cease sending
967    requests on that connection and close the connection after reading
968    the response message containing the close; if additional pipelined
969    requests had been sent on the connection, the client SHOULD NOT
970    assume that they will be processed by the server.
971
972NEW:
973
974    A client that receives a "close" connection option MUST cease sending
975    requests on that connection and close the connection after reading
976    the response message containing the close; if additional pipelined
977    requests had been sent on the connection, the client SHOULD NOT
978    assume that they will be processed by the server.
979
980
981Section 6.5., paragraph 12:
982OLD:
983
984    If a server performs an immediate close of a TCP connection, there is
985    a significant risk that the client will not be able to read the last
986    HTTP response.  If the server receives additional data from the
987    client on a fully-closed connection, such as another request that was
988    sent by the client before receiving the server's response, the
989    server's TCP stack will send a reset packet to the client;
990    unfortunately, the reset packet might erase the client's
991    unacknowledged input buffers before they can be read and interpreted
992    by the client's HTTP parser.
993
994NEW:
995
996    If a server performs an immediate close of a TCP connection, there is
997    a significant risk that the client will not be able to read the last
998    HTTP response.  If the server receives additional data from the
999    client on a fully closed connection, such as another request that was
1000    sent by the client before receiving the server's response, the
1001    server's TCP stack will send a reset packet to the client;
1002    unfortunately, the reset packet might erase the client's
1003    unacknowledged input buffers before they can be read and interpreted
1004    by the client's HTTP parser.
1005
1006
1007Section 6.7., paragraph 9:
1008OLD:
1009
1010    The capabilities and nature of the application-level communication
1011    after the protocol change is entirely dependent upon the new
1012    protocol(s) chosen.  However, immediately after sending the 101
1013    response, the server is expected to continue responding to the
1014    original request as if it had received its equivalent within the new
1015    protocol (i.e., the server still has an outstanding request to
1016    satisfy after the protocol has been changed, and is expected to do so
1017    without requiring the request to be repeated).
1018
1019NEW:
1020
1021    The capabilities and nature of the application-level communication
1022    after the protocol change is entirely dependent upon the new
1023    protocol(s) chosen.  However, immediately after sending the 101
1024    (Switching Protocols) response, the server is expected to continue
1025    responding to the original request as if it had received its
1026    equivalent within the new protocol (i.e., the server still has an
1027    outstanding request to satisfy after the protocol has been changed,
1028    and is expected to do so without requiring the request to be
1029    repeated).
1030
1031
1032Section 7., paragraph 14:
1033OLD:
1034
1035    Then the following are valid values for example-list (not including
1036    the double quotes, which are present for delimitation only):
1037
1038NEW:
1039
1040    Then, the following are valid values for example-list (not including
1041    the double quotes, which are present for delimitation only):
1042
1043
1044Section 8.1., paragraph 1:
1045OLD:
1046
1047    HTTP header fields are registered within the Message Header Field
1048    Registry maintained at
1049    <http://www.iana.org/assignments/message-headers/>.
1050
1051NEW:
1052
1053    HTTP header fields are registered within the "Message Header" field
1054    registry maintained at
1055    <http://www.iana.org/assignments/message-headers/>.
1056
1057
1058Section 8.1., paragraph 2:
1059OLD:
1060
1061    This document defines the following HTTP header fields, so their
1062    associated registry entries shall be updated according to the
1063    permanent registrations below (see [BCP90]):
1064
1065NEW:
1066
1067    This document defines the following HTTP header fields, so the
1068    "Permanent Message Header Field Names" registry has been updated
1069    accordingly (see [BCP90]).
1070
1071
1072Section 8.1., paragraph 4:
1073OLD:
1074
1075    Furthermore, the header field-name "Close" shall be registered as
1076    "reserved", since using that name as an HTTP header field might
1077    conflict with the "close" connection option of the "Connection"
1078    header field (Section 6.1).
1079
1080NEW:
1081
1082    Furthermore, the header field-name "Close" has been registered as
1083    "reserved", since using that name as an HTTP header field might
1084    conflict with the "close" connection option of the "Connection"
1085    header field (Section 6.1).
1086
1087
1088Section 8.2., paragraph 2:
1089OLD:
1090
1091    This document defines the following URI schemes, so their associated
1092    registry entries shall be updated according to the permanent
1093    registrations below:
1094
1095NEW:
1096
1097    This document defines the following URI schemes, so the "Permanent
1098    URI Schemes" registry has been updated accordingly.
1099
1100
1101Section 8.3., paragraph 2:
1102OLD:
1103
1104    This document serves as the specification for the Internet media
1105    types "message/http" and "application/http".  The following is to be
1106    registered with IANA.
1107
1108NEW:
1109
1110    This document serves as the specification for the Internet media
1111    types "message/http" and "application/http".  The following has been
1112    registered with IANA.
1113
1114
1115Section 8.3.1., paragraph 18:
1116OLD:
1117
1118    Person and email address to contact for further information:  See
1119       Authors' Addresses Section.
1120
1121NEW:
1122
1123    Person and email address to contact for further information:
1124       See Authors' Addresses  Section.
1125
1126
1127Section 8.3.2., paragraph 8:
1128OLD:
1129
1130    Encoding considerations:  HTTP messages enclosed by this type are in
1131       "binary" format; use of an appropriate Content-Transfer-Encoding
1132       is required when transmitted via E-mail.
1133
1134NEW:
1135
1136    Encoding considerations:  HTTP messages enclosed by this type are in
1137       "binary" format; use of an appropriate Content-Transfer-Encoding
1138       is required when transmitted via email.
1139
1140
1141Section 8.3.2., paragraph 19:
1142OLD:
1143
1144    Person and email address to contact for further information:  See
1145       Authors' Addresses Section.
1146
1147NEW:
1148
1149    Person and email address to contact for further information:
1150       See Authors' Addresses Section.
1151
1152
1153Section 8.4., paragraph 1:
1154OLD:
1155
1156    The HTTP Transfer Coding Registry defines the name space for transfer
1157    coding names.  It is maintained at
1158    <http://www.iana.org/assignments/http-parameters>.
1159
1160NEW:
1161
1162    The "HTTP Transfer Coding" registry defines the namespace for
1163    transfer coding names.  It is maintained at
1164    <http://www.iana.org/assignments/http-parameters>.
1165
1166
1167Section 8.4.1., paragraph 5:
1168OLD:
1169
1170    Values to be added to this name space require IETF Review (see
1171    Section 4.1 of [RFC5226]), and MUST conform to the purpose of
1172    transfer coding defined in this specification.
1173
1174NEW:
1175
1176    Values to be added to this namespace require IETF Review (see Section
1177    4.1 of [RFC5226]), and MUST conform to the purpose of transfer coding
1178    defined in this specification.
1179
1180
1181Section 8.4.2., paragraph 1:
1182OLD:
1183
1184    The HTTP Transfer Coding Registry shall be updated with the
1185    registrations below:
1186
1187NEW:
1188
1189    The "HTTP Transfer Coding Registry" has been updated with the
1190    registrations below:
1191
1192
1193Section 8.5., paragraph 1:
1194OLD:
1195
1196    IANA maintains the registry of HTTP Content Codings at
1197    <http://www.iana.org/assignments/http-parameters>.
1198
1199NEW:
1200
1201    IANA maintains the "HTTP Content Coding Registry" at
1202    <http://www.iana.org/assignments/http-parameters>.
1203
1204
1205Section 8.5., paragraph 2:
1206OLD:
1207
1208    The HTTP Content Codings Registry shall be updated with the
1209    registrations below:
1210
1211NEW:
1212
1213    The "HTTP Content Codings Registry" has been updated with the
1214    registrations below:
1215
1216
1217Section 8.6., paragraph 1:
1218OLD:
1219
1220    The HTTP Upgrade Token Registry defines the name space for protocol-
1221    name tokens used to identify protocols in the Upgrade header field.
1222    The registry is maintained at
1223    <http://www.iana.org/assignments/http-upgrade-tokens>.
1224
1225NEW:
1226
1227    The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
1228    defines the namespace for protocol-name tokens used to identify
1229    protocols in the Upgrade header field.  The registry is maintained at
1230    <http://www.iana.org/assignments/http-upgrade-tokens>.
1231
1232
1233Section 8.6.2., paragraph 1:
1234OLD:
1235
1236    The "HTTP" entry in the HTTP Upgrade Token Registry shall be updated
1237    with the registration below:
1238
1239NEW:
1240
1241    The "HTTP" entry in the "HTTP Upgrade Token" registry shall be
1242    updated with the registration below:
1243
1244
1245Section 9.1., paragraph 3:
1246OLD:
1247
1248    When a registered name is used in the authority component, the "http"
1249    URI scheme (Section 2.7.1) relies on the user's local name resolution
1250    service to determine where it can find authoritative responses.  This
1251    means that any attack on a user's network host table, cached names,
1252    or name resolution libraries becomes an avenue for attack on
1253    establishing authority.  Likewise, the user's choice of server for
1254    Domain Name Service (DNS), and the hierarchy of servers from which it
1255    obtains resolution results, could impact the authenticity of address
1256    mappings; DNSSEC ([RFC4033]) is one way to improve authenticity.
1257
1258NEW:
1259
1260    When a registered name is used in the authority component, the "http"
1261    URI scheme (Section 2.7.1) relies on the user's local name resolution
1262    service to determine where it can find authoritative responses.  This
1263    means that any attack on a user's network host table, cached names,
1264    or name resolution libraries becomes an avenue for attack on
1265    establishing authority.  Likewise, the user's choice of server for
1266    Domain Name Service (DNS), and the hierarchy of servers from which it
1267    obtains resolution results, could impact the authenticity of address
1268    mappings; DNS Security Extensions (DNSSEC) ([RFC4033]) is one way to
1269    improve authenticity.
1270
1271
1272Section 9.2., paragraph 1:
1273OLD:
1274
1275    By their very nature, HTTP intermediaries are men-in-the-middle, and
1276    thus represent an opportunity for man-in-the-middle attacks.
1277    Compromise of the systems on which the intermediaries run can result
1278    in serious security and privacy problems.  Intermediaries might have
1279    access to security-related information, personal information about
1280    individual users and organizations, and proprietary information
1281    belonging to users and content providers.  A compromised
1282    intermediary, or an intermediary implemented or configured without
1283    regard to security and privacy considerations, might be used in the
1284    commission of a wide range of potential attacks.
1285
1286NEW:
1287
1288    By their very nature, HTTP intermediaries are men in the middle and,
1289    thus, represent an opportunity for man-in-the-middle attacks.
1290    Compromise of the systems on which the intermediaries run can result
1291    in serious security and privacy problems.  Intermediaries might have
1292    access to security-related information, personal information about
1293    individual users and organizations, and proprietary information
1294    belonging to users and content providers.  A compromised
1295    intermediary, or an intermediary implemented or configured without
1296    regard to security and privacy considerations, might be used in the
1297    commission of a wide range of potential attacks.
1298
1299
1300Section 9.6., paragraph 2:
1301OLD:
1302
1303    User agents are encouraged to implement configurable means for
1304    detecting and reporting failures of message integrity such that those
1305    means can be enabled within environments for which integrity is
1306    necessary.  For example, a browser being used to view medical history
1307    or drug interaction information needs to indicate to the user when
1308    such information is detected by the protocol to be incomplete,
1309    expired, or corrupted during transfer.  Such mechanisms might be
1310    selectively enabled via user agent extensions or the presence of
1311    message integrity metadata in a response.  At a minimum, user agents
1312    ought to provide some indication that allows a user to distinguish
1313    between a complete and incomplete response message (Section 3.4) when
1314    such verification is desired.
1315
1316NEW:
1317
1318    User agents are encouraged to implement configurable means for
1319    detecting and reporting failures of message integrity such that those
1320    means can be enabled within environments for which integrity is
1321    necessary.  For example, a browser being used to view medical history
1322    or drug interaction information needs to indicate to the user when
1323    such information is detected by the protocol to be incomplete,
1324    expired, or corrupted during transfer.  Such mechanisms might be
1325    selectively enabled via user-agent extensions or the presence of
1326    message integrity metadata in a response.  At a minimum, user agents
1327    ought to provide some indication that allows a user to distinguish
1328    between a complete and incomplete response message (Section 3.4) when
1329    such verification is desired.
1330
1331
1332Section 11.1., paragraph 1:
1333OLD:
1334
1335    [RFC0793]     Postel, J., "Transmission Control Protocol", STD 7,
1336                  RFC 793, September 1981.
1337 
1338    [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
1339                  Format Specification version 3.3", RFC 1950, May 1996.
1340
1341NEW:
1342
1343    [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
1344                  Format Specification version 3.3", RFC 1950, May 1996.
1345
1346
1347Section 11.1., paragraph 7:
1348OLD:
1349
1350    [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1351                  Transfer Protocol (HTTP/1.1): Semantics and Content",
1352                  draft-ietf-httpbis-p2-semantics-latest (work in
1353                  progress), May 2014.
1354
1355NEW:
1356
1357    [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1358                  Transfer Protocol (HTTP/1.1): Semantics and Content",
1359                  RFC 7231, May 2014.
1360
1361
1362Section 11.1., paragraph 8:
1363OLD:
1364
1365    [RFC7232]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1366                  Transfer Protocol (HTTP/1.1): Conditional Requests",
1367                  draft-ietf-httpbis-p4-conditional-latest (work in
1368                  progress), May 2014.
1369
1370NEW:
1371
1372    [RFC7232]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1373                  Transfer Protocol (HTTP/1.1): Conditional Requests",
1374                  RFC 7232, May 2014.
1375
1376
1377Section 11.1., paragraph 9:
1378OLD:
1379
1380    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1381                  "Hypertext Transfer Protocol (HTTP/1.1): Range
1382                  Requests", draft-ietf-httpbis-p5-range-latest (work in
1383                  progress), May 2014.
1384
1385NEW:
1386
1387    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1388                  "Hypertext Transfer Protocol (HTTP/1.1): Range
1389                  Requests", RFC 7233, May 2014.
1390
1391
1392Section 11.1., paragraph 10:
1393OLD:
1394
1395    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1396                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1397                  draft-ietf-httpbis-p6-cache-latest (work in progress),
1398                  May 2014.
1399
1400NEW:
1401
1402    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1403                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1404                  RFC 7234, May 2014.
1405
1406
1407Section 11.1., paragraph 11:
1408OLD:
1409
1410    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1411                  Transfer Protocol (HTTP/1.1): Authentication",
1412                  draft-ietf-httpbis-p7-auth-latest (work in progress),
1413                  May 2014.
1414
1415NEW:
1416
1417    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1418                  Transfer Protocol (HTTP/1.1): Authentication",
1419                  RFC 7235, May 2014.
1420 
1421    [RFC793]      Postel, J., "Transmission Control Protocol", STD 7,
1422                  RFC 793, September 1981.
1423
1424
1425Section 11.1., paragraph 13:
1426OLD:
1427
1428    [Welch]       Welch, T., "A Technique for High Performance Data
1429                  Compression", IEEE Computer 17(6), June 1984.
1430
1431NEW:
1432
1433    [Welch]       Welch, T., "A Technique for High-Performance Data
1434                  Compression", IEEE Computer 17(6), June 1984.
1435
1436
1437Appendix A., paragraph 1:
1438OLD:
1439
1440    HTTP has been in use since 1990.  The first version, later referred
1441    to as HTTP/0.9, was a simple protocol for hypertext data transfer
1442    across the Internet, using only a single request method (GET) and no
1443    metadata.  HTTP/1.0, as defined by [RFC1945], added a range of
1444    request methods and MIME-like messaging, allowing for metadata to be
1445    transferred and modifiers placed on the request/response semantics.
1446    However, HTTP/1.0 did not sufficiently take into consideration the
1447    effects of hierarchical proxies, caching, the need for persistent
1448    connections, or name-based virtual hosts.  The proliferation of
1449    incompletely-implemented applications calling themselves "HTTP/1.0"
1450    further necessitated a protocol version change in order for two
1451    communicating applications to determine each other's true
1452    capabilities.
1453
1454NEW:
1455
1456    HTTP has been in use since 1990.  The first version, later referred
1457    to as HTTP/0.9, was a simple protocol for hypertext data transfer
1458    across the Internet, using only a single request method (GET) and no
1459    metadata.  HTTP/1.0, as defined by [RFC1945], added a range of
1460    request methods and MIME-like messaging, allowing for metadata to be
1461    transferred and modifiers placed on the request/response semantics.
1462    However, HTTP/1.0 did not sufficiently take into consideration the
1463    effects of hierarchical proxies, caching, the need for persistent
1464    connections, or name-based virtual hosts.  The proliferation of
1465    incompletely implemented applications calling themselves "HTTP/1.0"
1466    further necessitated a protocol version change in order for two
1467    communicating applications to determine each other's true
1468    capabilities.
1469
1470
1471Appendix A., paragraph 7:
1472OLD:
1473
1474 A.1.1.  Multi-homed Web Servers
1475
1476NEW:
1477
1478 A.1.1.  Multihomed Web Servers
1479
1480
1481Section 19.7.1, paragraph 8:
1482OLD:
1483
1484    HTTP's approach to error handling has been explained.  (Section 2.5)
1485
1486NEW:
1487
1488    HTTP's approach to error handling has been explained (Section 2.5).
1489
1490
1491Section 19.7.1, paragraph 9:
1492OLD:
1493
1494    The HTTP-version ABNF production has been clarified to be case-
1495    sensitive.  Additionally, version numbers have been restricted to
1496    single digits, due to the fact that implementations are known to
1497    handle multi-digit version numbers incorrectly.  (Section 2.6)
1498
1499NEW:
1500
1501    The HTTP-version ABNF production has been clarified to be case
1502    sensitive.  Additionally, version numbers have been restricted to
1503    single digits, due to the fact that implementations are known to
1504    handle multi-digit version numbers incorrectly (Section 2.6).
1505
1506
1507Section 19.7.1, paragraph 10:
1508OLD:
1509
1510    Userinfo (i.e., username and password) are now disallowed in HTTP and
1511    HTTPS URIs, because of security issues related to their transmission
1512    on the wire.  (Section 2.7.1)
1513
1514NEW:
1515
1516    Userinfo (i.e., username and password) are now disallowed in HTTP and
1517    HTTPS URIs, because of security issues related to their transmission
1518    on the wire (Section 2.7.1).
1519
1520
1521Section 19.7.1, paragraph 11:
1522OLD:
1523
1524    The HTTPS URI scheme is now defined by this specification;
1525    previously, it was done in Section 2.4 of [RFC2818].  Furthermore, it
1526    implies end-to-end security.  (Section 2.7.2)
1527
1528NEW:
1529
1530    The HTTPS URI scheme is now defined by this specification;
1531    previously, it was defined in Section 2.4 of [RFC2818].  Furthermore,
1532    it implies end-to-end security (Section 2.7.2).
1533
1534
1535Section 19.7.1, paragraph 12:
1536OLD:
1537
1538    HTTP messages can be (and often are) buffered by implementations;
1539    despite it sometimes being available as a stream, HTTP is
1540    fundamentally a message-oriented protocol.  Minimum supported sizes
1541    for various protocol elements have been suggested, to improve
1542    interoperability.  (Section 3)
1543
1544NEW:
1545
1546    HTTP messages can be (and often are) buffered by implementations;
1547    despite it sometimes being available as a stream, HTTP is
1548    fundamentally a message-oriented protocol.  Minimum supported sizes
1549    for various protocol elements have been suggested, to improve
1550    interoperability (Section 3).
1551
1552
1553Section 19.7.1, paragraph 13:
1554OLD:
1555
1556    Invalid whitespace around field-names is now required to be rejected,
1557    because accepting it represents a security vulnerability.  The ABNF
1558    productions defining header fields now only list the field value.
1559    (Section 3.2)
1560
1561NEW:
1562
1563    Invalid whitespace around field-names is now required to be rejected,
1564    because accepting it represents a security vulnerability.  The ABNF
1565    productions defining header fields now only list the field value
1566    (Section 3.2).
1567
1568
1569Section 19.7.1, paragraph 14:
1570OLD:
1571
1572    Rules about implicit linear whitespace between certain grammar
1573    productions have been removed; now whitespace is only allowed where
1574    specifically defined in the ABNF.  (Section 3.2.3)
1575
1576NEW:
1577
1578    Rules about implicit linear whitespace between certain grammar
1579    productions have been removed; now whitespace is only allowed where
1580    specifically defined in the ABNF (Section 3.2.3).
1581
1582
1583Section 19.7.1, paragraph 15:
1584OLD:
1585
1586    Header fields that span multiple lines ("line folding") are
1587    deprecated.  (Section 3.2.4)
1588    The NUL octet is no longer allowed in comment and quoted-string text,
1589    and handling of backslash-escaping in them has been clarified.  The
1590    quoted-pair rule no longer allows escaping control characters other
1591    than HTAB.  Non-ASCII content in header fields and the reason phrase
1592    has been obsoleted and made opaque (the TEXT rule was removed).
1593    (Section 3.2.6)
1594
1595NEW:
1596
1597    Header fields that span multiple lines ("line folding") are
1598    deprecated (Section 3.2.4).
1599 
1600    The NUL octet is no longer allowed in comment and quoted-string text,
1601    and handling of backslash-escaping in them has been clarified.  The
1602    quoted-pair rule no longer allows escaping control characters other
1603    than HTAB.  Non-US-ASCII content in header fields and the reason
1604    phrase has been obsoleted and made opaque (the TEXT rule was removed)
1605    (Section 3.2.6).
1606
1607
1608Section 19.7.1, paragraph 16:
1609OLD:
1610
1611    Bogus "Content-Length" header fields are now required to be handled
1612    as errors by recipients.  (Section 3.3.2)
1613
1614NEW:
1615
1616    Bogus "Content-Length" header fields are now required to be handled
1617    as errors by recipients (Section 3.3.2).
1618
1619
1620Section 19.7.1, paragraph 17:
1621OLD:
1622
1623    The algorithm for determining the message body length has been
1624    clarified to indicate all of the special cases (e.g., driven by
1625    methods or status codes) that affect it, and that new protocol
1626    elements cannot define such special cases.  CONNECT is a new, special
1627    case in determining message body length. "multipart/byteranges" is no
1628    longer a way of determining message body length detection.
1629    (Section 3.3.3)
1630
1631NEW:
1632
1633    The algorithm for determining the message body length has been
1634    clarified to indicate all of the special cases (e.g., driven by
1635    methods or status codes) that affect it, and that new protocol
1636    elements cannot define such special cases.  CONNECT is a new, special
1637    case in determining message body length. "multipart/byteranges" is no
1638    longer a way of determining message body length detection
1639    (Section 3.3.3).
1640
1641
1642Section 19.7.1, paragraph 18:
1643OLD:
1644
1645    The "identity" transfer coding token has been removed.  (Sections 3.3
1646    and 4)
1647
1648NEW:
1649
1650    The "identity" transfer coding token has been removed (Sections 3.3
1651    and 4).
1652
1653
1654Section 19.7.1, paragraph 19:
1655OLD:
1656
1657    Chunk length does not include the count of the octets in the chunk
1658    header and trailer.  Line folding in chunk extensions is disallowed.
1659    (Section 4.1)
1660
1661NEW:
1662
1663    Chunk length does not include the count of the octets in the chunk
1664    header and trailer.  Line folding in chunk extensions is disallowed
1665    (Section 4.1).
1666
1667
1668Section 19.7.1, paragraph 20:
1669OLD:
1670
1671    The meaning of the "deflate" content coding has been clarified.
1672    (Section 4.2.2)
1673
1674NEW:
1675
1676    The meaning of the "deflate" content coding has been clarified
1677    (Section 4.2.2).
1678
1679
1680Section 19.7.1, paragraph 21:
1681OLD:
1682
1683    The segment + query components of RFC 3986 have been used to define
1684    the request-target, instead of abs_path from RFC 1808.  The asterisk-
1685    form of the request-target is only allowed with the OPTIONS method.
1686    (Section 5.3)
1687
1688NEW:
1689
1690    The segment + query components of RFC 3986 have been used to define
1691    the request-target, instead of abs_path from RFC 1808.  The asterisk-
1692    form of the request-target is only allowed with the OPTIONS method
1693    (Section 5.3).
1694
1695
1696Section 19.7.1, paragraph 22:
1697OLD:
1698
1699    The term "Effective Request URI" has been introduced.  (Section 5.5)
1700
1701NEW:
1702
1703    The term "Effective Request URI" has been introduced (Section 5.5).
1704
1705
1706Section 19.7.1, paragraph 23:
1707OLD:
1708
1709    Gateways do not need to generate Via header fields anymore.
1710    (Section 5.7.1)
1711
1712NEW:
1713
1714    Gateways do not need to generate Via header fields anymore
1715    (Section 5.7.1).
1716
1717
1718Section 19.7.1, paragraph 24:
1719OLD:
1720
1721    Exactly when "close" connection options have to be sent has been
1722    clarified.  Also, "hop-by-hop" header fields are required to appear
1723    in the Connection header field; just because they're defined as hop-
1724    by-hop in this specification doesn't exempt them.  (Section 6.1)
1725
1726NEW:
1727
1728    Exactly when "close" connection options have to be sent has been
1729    clarified.  Also, "hop-by-hop" header fields are required to appear
1730    in the Connection header field; just because they're defined as hop-
1731    by-hop in this specification doesn't exempt them (Section 6.1).
1732
1733
1734Section 19.7.1, paragraph 25:
1735OLD:
1736
1737    The limit of two connections per server has been removed.  An
1738    idempotent sequence of requests is no longer required to be retried.
1739    The requirement to retry requests under certain circumstances when
1740    the server prematurely closes the connection has been removed.  Also,
1741    some extraneous requirements about when servers are allowed to close
1742    connections prematurely have been removed.  (Section 6.3)
1743
1744NEW:
1745
1746    The limit of two connections per server has been removed.  An
1747    idempotent sequence of requests is no longer required to be retried.
1748    The requirement to retry requests under certain circumstances when
1749    the server prematurely closes the connection has been removed.  Also,
1750    some extraneous requirements about when servers are allowed to close
1751    connections prematurely have been removed (Section 6.3).
1752
1753
1754Section 19.7.1, paragraph 26:
1755OLD:
1756
1757    The semantics of the Upgrade header field is now defined in responses
1758    other than 101 (this was incorporated from [RFC2817]).  Furthermore,
1759    the ordering in the field value is now significant.  (Section 6.7)
1760
1761NEW:
1762
1763    The semantics of the Upgrade header field is now defined in responses
1764    other than 101 (this was incorporated from [RFC2817]).  Furthermore,
1765    the ordering in the field value is now significant (Section 6.7).
1766
1767
1768Section 19.7.1, paragraph 27:
1769OLD:
1770
1771    Empty list elements in list productions (e.g., a list header field
1772    containing ", ,") have been deprecated.  (Section 7)
1773
1774NEW:
1775
1776    Empty list elements in list productions (e.g., a list header field
1777    containing ", ,") have been deprecated (Section 7).
1778
1779
1780Section 19.7.1, paragraph 28:
1781OLD:
1782
1783    Registration of Transfer Codings now requires IETF Review
1784    (Section 8.4)
1785
1786NEW:
1787
1788    Registration of Transfer Codings now requires IETF Review
1789    (Section 8.4).
1790
1791
1792Section 19.7.1, paragraph 29:
1793OLD:
1794
1795    This specification now defines the Upgrade Token Registry, previously
1796    defined in Section 7.2 of [RFC2817].  (Section 8.6)
1797
1798NEW:
1799
1800    This specification now defines the "HTTP Upgrade Tokens" registry,
1801    previously defined in Section 7.2 of [RFC2817] (Section 8.6).
1802
1803
1804Section 19.7.1, paragraph 30:
1805OLD:
1806
1807    The expectation to support HTTP/0.9 requests has been removed.
1808    (Appendix A)
1809
1810NEW:
1811
1812    The expectation to support HTTP/0.9 requests has been removed
1813    (Appendix A).
1814
1815
1816Section 19.7.1, paragraph 31:
1817OLD:
1818
1819    Issues with the Keep-Alive and Proxy-Connection header fields in
1820    requests are pointed out, with use of the latter being discouraged
1821    altogether.  (Appendix A.1.2)
1822
1823NEW:
1824
1825    Issues with the Keep-Alive and Proxy-Connection header fields in
1826    requests are pointed out, with use of the latter being discouraged
1827    altogether (Appendix A.1.2).
1828
1829
1830Appendix B., paragraph 7:
1831OLD:
1832
1833    URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
1834    Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
1835    Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
1836     ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
1837     comment ] ) ] )
1838
1839NEW:
1840
1841    URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
1842    Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
1843 
1844    Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
1845     ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
1846     comment ] ) ] )
1847
1848
1849Appendix B., paragraph 15:
1850OLD:
1851
1852    partial-URI = relative-part [ "?" query ]
1853    path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
1854    port = <port, defined in [RFC3986], Section 3.2.3>
1855    protocol = protocol-name [ "/" protocol-version ]
1856    protocol-name = token
1857    protocol-version = token
1858    pseudonym = token
1859 
1860    qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
1861     / %x5D-7E ; ']'-'~'
1862     / obs-text
1863    query = <query, defined in [RFC3986], Section 3.4>
1864    quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
1865    quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
1866
1867NEW:
1868
1869    partial-URI = relative-part [ "?" query ]
1870    path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
1871    port = <port, defined in [RFC3986], Section 3.2.3>
1872    protocol = protocol-name [ "/" protocol-version ]
1873    protocol-name = token
1874    protocol-version = token
1875    pseudonym = token
1876    qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
1877     / %x5D-7E ; ']'-'~'
1878     / obs-text
1879    query = <query, defined in [RFC3986], Section 3.4>
1880    quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
1881    quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
1882
1883
1884Appendix B., paragraph 24:
1885OLD:
1886
1887    D
1888       deflate (Coding Format)  38
1889       Delimiters  26
1890       downstream  9
1891
1892NEW:
1893
1894    D
1895       deflate (Coding Format)  38
1896       Delimiters  26
1897       downstream  10
1898
1899
1900Appendix B., paragraph 26:
1901OLD:
1902
1903    G
1904       gateway  10
1905       Grammar
1906          absolute-form  41-42
1907          absolute-path  16
1908          absolute-URI  16
1909          ALPHA  6
1910          asterisk-form  41-42
1911          authority  16
1912          authority-form  41-42
1913          BWS  24
1914          chunk  35
1915          chunk-data  35
1916          chunk-ext  35-36
1917          chunk-ext-name  36
1918          chunk-ext-val  36
1919          chunk-size  35
1920          chunked-body  35-36
1921          comment  27
1922          Connection  51
1923          connection-option  51
1924          Content-Length  30
1925          CR  6
1926          CRLF  6
1927          ctext  27
1928          CTL  6
1929          DIGIT  6
1930          DQUOTE  6
1931          field-content  22
1932          field-name  22, 39
1933          field-value  22
1934          field-vchar  22
1935          fragment  16
1936          header-field  22, 36
1937          HEXDIG  6
1938          Host  43
1939          HTAB  6
1940          HTTP-message  19
1941          HTTP-name  13
1942          http-URI  16
1943          HTTP-version  13
1944          https-URI  18
1945          last-chunk  35
1946          LF  6
1947          message-body  27
1948          method  21
1949          obs-fold  22
1950          obs-text  27
1951          OCTET  6
1952          origin-form  41
1953          OWS  24
1954          partial-URI  16
1955          port  16
1956          protocol-name  47
1957          protocol-version  47
1958          pseudonym  47
1959          qdtext  27
1960          query  16
1961          quoted-pair  27
1962          quoted-string  27
1963          rank  38
1964          reason-phrase  22
1965          received-by  47
1966          received-protocol  47
1967          request-line  21
1968          request-target  41
1969          RWS  24
1970          scheme  16
1971          segment  16
1972          SP  6
1973          start-line  20
1974          status-code  22
1975          status-line  22
1976          t-codings  38
1977          t-ranking  38
1978          tchar  27
1979          TE  38
1980          token  27
1981          Trailer  39
1982          trailer-part  35-36
1983          transfer-coding  35
1984          Transfer-Encoding  28
1985          transfer-extension  35
1986          transfer-parameter  35
1987          Upgrade  56
1988          uri-host  16
1989          URI-reference  16
1990          VCHAR  6
1991          Via  47
1992       gzip (Coding Format)  38
1993
1994NEW:
1995
1996    G
1997       gateway  10
1998       Grammar
1999          absolute-form  41-42
2000          absolute-path  16
2001          absolute-URI  16
2002          ALPHA  6
2003          asterisk-form  41-42
2004          authority  16
2005          authority-form  41-42
2006          BWS  24
2007          chunk  35
2008          chunk-data  35
2009          chunk-ext  35-36
2010          chunk-ext-name  36
2011          chunk-ext-val  36
2012          chunk-size  35
2013          chunked-body  35-36
2014          comment  27
2015          Connection  51
2016          connection-option  51
2017          Content-Length  30
2018          CR  6
2019          CRLF  6
2020          ctext  27
2021          CTL  6
2022          DIGIT  6
2023          DQUOTE  6
2024          field-content  22
2025          field-name  22, 39
2026          field-value  22
2027          field-vchar  22
2028          fragment  16
2029          header-field  22, 36
2030          HEXDIG  6
2031          Host  43
2032          HTAB  6
2033          HTTP-message  19
2034          HTTP-name  14
2035          http-URI  16
2036          HTTP-version  14
2037          https-URI  18
2038          last-chunk  35
2039          LF  6
2040          message-body  27
2041          method  21
2042          obs-fold  22
2043          obs-text  27
2044          OCTET  6
2045          origin-form  41
2046          OWS  24
2047          partial-URI  16
2048          port  16
2049          protocol-name  47
2050          protocol-version  47
2051          pseudonym  47
2052          qdtext  27
2053          query  16
2054          quoted-pair  27
2055          quoted-string  27
2056          rank  38
2057          reason-phrase  22
2058          received-by  47
2059          received-protocol  47
2060          request-line  21
2061          request-target  41
2062          RWS  24
2063          scheme  16
2064          segment  16
2065          SP  6
2066          start-line  20
2067          status-code  22
2068          status-line  22
2069          t-codings  38
2070          t-ranking  38
2071          tchar  27
2072          TE  38
2073          token  27
2074          Trailer  39
2075          trailer-part  35-36
2076          transfer-coding  35
2077          Transfer-Encoding  28
2078          transfer-extension  35
2079          transfer-parameter  35
2080          Upgrade  56
2081          uri-host  16
2082          URI-reference  16
2083          VCHAR  6
2084          Via  47
2085       gzip (Coding Format)  38
2086
2087
2088Appendix B., paragraph 28:
2089OLD:
2090
2091    I
2092       inbound  9
2093       interception proxy  11
2094       intermediary  9
2095
2096NEW:
2097
2098    I
2099       inbound  10
2100       interception proxy  11
2101       intermediary  9
2102
2103
2104Appendix B., paragraph 31:
2105OLD:
2106
2107    O
2108       origin server  7
2109       origin-form (of request-target)  41
2110       outbound  9
2111
2112NEW:
2113
2114    O
2115       origin server  7
2116       origin-form (of request-target)  41
2117       outbound  10
2118
2119
2120Appendix B., paragraph 36:
2121OLD:
2122
2123    U
2124       Upgrade header field  56
2125       upstream  9
2126       URI scheme
2127          http  16
2128          https  18
2129       user agent  7
2130
2131NEW:
2132
2133    U
2134       Upgrade header field  56
2135       upstream  10
2136       URI scheme
2137          http  16
2138          https  18
2139       user agent  7
2140
2141
2142Section 345, paragraph 1:
2143OLD:
2144
2145    EMail: fielding@gbiv.com
2146    URI:   http://roy.gbiv.com/
2147 
2148    Julian F. Reschke (editor)
2149    greenbytes GmbH
2150    Hafenweg 16
2151    Muenster, NW  48155
2152    Germany
2153
2154NEW:
2155
2156    EMail: fielding@gbiv.com
2157    URI:   http://roy.gbiv.com/
2158    Julian F. Reschke (editor)
2159    greenbytes GmbH
2160    Hafenweg 16
2161    Muenster, NW  48155
2162    Germany
2163
Note: See TracBrowser for help on using the repository browser.