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

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

hyphenation (#553)

File size: 72.3 KB
Line 
1
2INTRODUCTION, paragraph 1:
3OLD:
4
5 HTTPbis Working Group                                   R. Fielding, Ed.
6 Internet-Draft                                                     Adobe
7 Obsoletes: 2145, 2616                                    J. Reschke, Ed.
8 (if approved)                                                 greenbytes
9 Updates: 2817, 2818 (if approved)                            May 7, 2014
10 Intended status: Standards Track
11 Expires: November 8, 2014
12
13NEW:
14
15 Internet Engineering Task Force (IETF)                  R. Fielding, Ed.
16 Request for Comments: 7230                                         Adobe
17 Obsoletes: 2145, 2616                                    J. Reschke, Ed.
18 Updates: 2817, 2818                                           greenbytes
19 Category: Standards Track                                       May 2014
20 ISSN: 2070-1721
21
22
23INTRODUCTION, paragraph 2:
24OLD:
25
26    Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
27                  draft-ietf-httpbis-p1-messaging-latest
28
29NEW:
30
31    Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
32
33
34INTRODUCTION, paragraph 5:
35OLD:
36
37 Editorial Note (To be removed by RFC Editor)
38 
39    Discussion of this draft takes place on the HTTPBIS working group
40    mailing list (ietf-http-wg@w3.org), which is archived at
41    <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
42 
43    The current issues list is at
44    <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
45    documents (including fancy diffs) can be found at
46    <http://tools.ietf.org/wg/httpbis/>.
47 
48    _This is a temporary document for the purpose of tracking the
49    editorial changes made during the AUTH48 (RFC publication) phase._
50 
51 Status of This Memo
52
53NEW:
54
55 Status of This Memo
56
57
58INTRODUCTION, paragraph 6:
59OLD:
60
61    This Internet-Draft is submitted in full conformance with the
62    provisions of BCP 78 and BCP 79.
63 
64    Internet-Drafts are working documents of the Internet Engineering
65    Task Force (IETF).  Note that other groups may also distribute
66    working documents as Internet-Drafts.  The list of current Internet-
67    Drafts is at http://datatracker.ietf.org/drafts/current/.
68
69NEW:
70
71    This is an Internet Standards Track document.
72
73
74INTRODUCTION, paragraph 7:
75OLD:
76
77    Internet-Drafts are draft documents valid for a maximum of six months
78    and may be updated, replaced, or obsoleted by other documents at any
79    time.  It is inappropriate to use Internet-Drafts as reference
80    material or to cite them other than as "work in progress."
81
82NEW:
83
84    This document is a product of the Internet Engineering Task Force
85    (IETF).  It represents the consensus of the IETF community.  It has
86    received public review and has been approved for publication by the
87    Internet Engineering Steering Group (IESG).  Further information on
88    Internet Standards is available in Section 2 of RFC 5741.
89
90
91INTRODUCTION, paragraph 8:
92OLD:
93
94    This Internet-Draft will expire on November 8, 2014.
95
96NEW:
97
98    Information about the current status of this document, any errata,
99    and how to provide feedback on it may be obtained at
100    http://www.rfc-editor.org/info/rfc7230.
101
102
103Section 11., paragraph 0:
104OLD:
105
106    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
107      1.1.  Requirements Notation  . . . . . . . . . . . . . . . . . .  6
108      1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  6
109    2.  Architecture . . . . . . . . . . . . . . . . . . . . . . . . .  6
110      2.1.  Client/Server Messaging  . . . . . . . . . . . . . . . . .  7
111      2.2.  Implementation Diversity . . . . . . . . . . . . . . . . .  8
112      2.3.  Intermediaries . . . . . . . . . . . . . . . . . . . . . .  9
113      2.4.  Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11
114      2.5.  Conformance and Error Handling . . . . . . . . . . . . . . 12
115      2.6.  Protocol Versioning  . . . . . . . . . . . . . . . . . . . 13
116      2.7.  Uniform Resource Identifiers . . . . . . . . . . . . . . . 16
117        2.7.1.  http URI Scheme  . . . . . . . . . . . . . . . . . . . 16
118        2.7.2.  https URI Scheme . . . . . . . . . . . . . . . . . . . 18
119        2.7.3.  http and https URI Normalization and Comparison  . . . 19
120 
121    3.  Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19
122      3.1.  Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20
123        3.1.1.  Request Line . . . . . . . . . . . . . . . . . . . . . 21
124        3.1.2.  Status Line  . . . . . . . . . . . . . . . . . . . . . 22
125      3.2.  Header Fields  . . . . . . . . . . . . . . . . . . . . . . 22
126        3.2.1.  Field Extensibility  . . . . . . . . . . . . . . . . . 23
127        3.2.2.  Field Order  . . . . . . . . . . . . . . . . . . . . . 23
128        3.2.3.  Whitespace . . . . . . . . . . . . . . . . . . . . . . 24
129        3.2.4.  Field Parsing  . . . . . . . . . . . . . . . . . . . . 25
130        3.2.5.  Field Limits . . . . . . . . . . . . . . . . . . . . . 26
131        3.2.6.  Field Value Components . . . . . . . . . . . . . . . . 26
132      3.3.  Message Body . . . . . . . . . . . . . . . . . . . . . . . 27
133        3.3.1.  Transfer-Encoding  . . . . . . . . . . . . . . . . . . 28
134        3.3.2.  Content-Length . . . . . . . . . . . . . . . . . . . . 30
135        3.3.3.  Message Body Length  . . . . . . . . . . . . . . . . . 31
136      3.4.  Handling Incomplete Messages . . . . . . . . . . . . . . . 33
137      3.5.  Message Parsing Robustness . . . . . . . . . . . . . . . . 34
138    4.  Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 35
139      4.1.  Chunked Transfer Coding  . . . . . . . . . . . . . . . . . 35
140        4.1.1.  Chunk Extensions . . . . . . . . . . . . . . . . . . . 36
141        4.1.2.  Chunked Trailer Part . . . . . . . . . . . . . . . . . 36
142        4.1.3.  Decoding Chunked . . . . . . . . . . . . . . . . . . . 37
143      4.2.  Compression Codings  . . . . . . . . . . . . . . . . . . . 38
144        4.2.1.  Compress Coding  . . . . . . . . . . . . . . . . . . . 38
145        4.2.2.  Deflate Coding . . . . . . . . . . . . . . . . . . . . 38
146        4.2.3.  Gzip Coding  . . . . . . . . . . . . . . . . . . . . . 38
147      4.3.  TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
148      4.4.  Trailer  . . . . . . . . . . . . . . . . . . . . . . . . . 39
149    5.  Message Routing  . . . . . . . . . . . . . . . . . . . . . . . 40
150      5.1.  Identifying a Target Resource  . . . . . . . . . . . . . . 40
151      5.2.  Connecting Inbound . . . . . . . . . . . . . . . . . . . . 40
152      5.3.  Request Target . . . . . . . . . . . . . . . . . . . . . . 41
153        5.3.1.  origin-form  . . . . . . . . . . . . . . . . . . . . . 41
154        5.3.2.  absolute-form  . . . . . . . . . . . . . . . . . . . . 42
155        5.3.3.  authority-form . . . . . . . . . . . . . . . . . . . . 42
156        5.3.4.  asterisk-form  . . . . . . . . . . . . . . . . . . . . 42
157      5.4.  Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
158      5.5.  Effective Request URI  . . . . . . . . . . . . . . . . . . 44
159      5.6.  Associating a Response to a Request  . . . . . . . . . . . 46
160      5.7.  Message Forwarding . . . . . . . . . . . . . . . . . . . . 46
161        5.7.1.  Via  . . . . . . . . . . . . . . . . . . . . . . . . . 47
162        5.7.2.  Transformations  . . . . . . . . . . . . . . . . . . . 48
163    6.  Connection Management  . . . . . . . . . . . . . . . . . . . . 49
164      6.1.  Connection . . . . . . . . . . . . . . . . . . . . . . . . 50
165      6.2.  Establishment  . . . . . . . . . . . . . . . . . . . . . . 51
166      6.3.  Persistence  . . . . . . . . . . . . . . . . . . . . . . . 52
167        6.3.1.  Retrying Requests  . . . . . . . . . . . . . . . . . . 53
168        6.3.2.  Pipelining . . . . . . . . . . . . . . . . . . . . . . 53
169 
170      6.4.  Concurrency  . . . . . . . . . . . . . . . . . . . . . . . 54
171      6.5.  Failures and Timeouts  . . . . . . . . . . . . . . . . . . 54
172      6.6.  Tear-down  . . . . . . . . . . . . . . . . . . . . . . . . 55
173      6.7.  Upgrade  . . . . . . . . . . . . . . . . . . . . . . . . . 56
174    7.  ABNF List Extension: #rule . . . . . . . . . . . . . . . . . . 58
175    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 60
176      8.1.  Header Field Registration  . . . . . . . . . . . . . . . . 60
177      8.2.  URI Scheme Registration  . . . . . . . . . . . . . . . . . 60
178      8.3.  Internet Media Type Registration . . . . . . . . . . . . . 61
179        8.3.1.  Internet Media Type message/http . . . . . . . . . . . 61
180        8.3.2.  Internet Media Type application/http . . . . . . . . . 62
181      8.4.  Transfer Coding Registry . . . . . . . . . . . . . . . . . 63
182        8.4.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 63
183        8.4.2.  Registration . . . . . . . . . . . . . . . . . . . . . 64
184      8.5.  Content Coding Registration  . . . . . . . . . . . . . . . 64
185      8.6.  Upgrade Token Registry . . . . . . . . . . . . . . . . . . 65
186        8.6.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 65
187        8.6.2.  Upgrade Token Registration . . . . . . . . . . . . . . 66
188    9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 66
189      9.1.  Establishing Authority . . . . . . . . . . . . . . . . . . 66
190      9.2.  Risks of Intermediaries  . . . . . . . . . . . . . . . . . 67
191      9.3.  Attacks via Protocol Element Length  . . . . . . . . . . . 68
192      9.4.  Response Splitting . . . . . . . . . . . . . . . . . . . . 68
193      9.5.  Request Smuggling  . . . . . . . . . . . . . . . . . . . . 69
194      9.6.  Message Integrity  . . . . . . . . . . . . . . . . . . . . 69
195      9.7.  Message Confidentiality  . . . . . . . . . . . . . . . . . 70
196      9.8.  Privacy of Server Log Information  . . . . . . . . . . . . 70
197    10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 71
198    11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
199      11.1. Normative References . . . . . . . . . . . . . . . . . . . 72
200      11.2. Informative References . . . . . . . . . . . . . . . . . . 74
201    Appendix A.  HTTP Version History  . . . . . . . . . . . . . . . . 76
202      A.1.  Changes from HTTP/1.0  . . . . . . . . . . . . . . . . . . 77
203        A.1.1.  Multi-homed Web Servers  . . . . . . . . . . . . . . . 77
204        A.1.2.  Keep-Alive Connections . . . . . . . . . . . . . . . . 77
205        A.1.3.  Introduction of Transfer-Encoding  . . . . . . . . . . 78
206      A.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 78
207    Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 80
208    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
209
210NEW:
211
212    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
213      1.1.  Requirements Notation  . . . . . . . . . . . . . . . . . .  6
214      1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  6
215    2.  Architecture . . . . . . . . . . . . . . . . . . . . . . . . .  6
216      2.1.  Client/Server Messaging  . . . . . . . . . . . . . . . . .  7
217      2.2.  Implementation Diversity . . . . . . . . . . . . . . . . .  8
218      2.3.  Intermediaries . . . . . . . . . . . . . . . . . . . . . .  9
219      2.4.  Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11
220      2.5.  Conformance and Error Handling . . . . . . . . . . . . . . 12
221      2.6.  Protocol Versioning  . . . . . . . . . . . . . . . . . . . 13
222      2.7.  Uniform Resource Identifiers . . . . . . . . . . . . . . . 16
223        2.7.1.  http URI Scheme  . . . . . . . . . . . . . . . . . . . 16
224        2.7.2.  https URI Scheme . . . . . . . . . . . . . . . . . . . 18
225        2.7.3.  http and https URI Normalization and Comparison  . . . 19
226    3.  Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19
227      3.1.  Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20
228        3.1.1.  Request Line . . . . . . . . . . . . . . . . . . . . . 21
229        3.1.2.  Status Line  . . . . . . . . . . . . . . . . . . . . . 22
230      3.2.  Header Fields  . . . . . . . . . . . . . . . . . . . . . . 22
231        3.2.1.  Field Extensibility  . . . . . . . . . . . . . . . . . 23
232        3.2.2.  Field Order  . . . . . . . . . . . . . . . . . . . . . 23
233        3.2.3.  Whitespace . . . . . . . . . . . . . . . . . . . . . . 24
234        3.2.4.  Field Parsing  . . . . . . . . . . . . . . . . . . . . 25
235        3.2.5.  Field Limits . . . . . . . . . . . . . . . . . . . . . 26
236        3.2.6.  Field Value Components . . . . . . . . . . . . . . . . 26
237      3.3.  Message Body . . . . . . . . . . . . . . . . . . . . . . . 27
238        3.3.1.  Transfer-Encoding  . . . . . . . . . . . . . . . . . . 28
239        3.3.2.  Content-Length . . . . . . . . . . . . . . . . . . . . 30
240        3.3.3.  Message Body Length  . . . . . . . . . . . . . . . . . 31
241      3.4.  Handling Incomplete Messages . . . . . . . . . . . . . . . 33
242      3.5.  Message Parsing Robustness . . . . . . . . . . . . . . . . 34
243    4.  Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 35
244      4.1.  Chunked Transfer Coding  . . . . . . . . . . . . . . . . . 35
245        4.1.1.  Chunk Extensions . . . . . . . . . . . . . . . . . . . 36
246        4.1.2.  Chunked Trailer Part . . . . . . . . . . . . . . . . . 36
247        4.1.3.  Decoding Chunked . . . . . . . . . . . . . . . . . . . 37
248      4.2.  Compression Codings  . . . . . . . . . . . . . . . . . . . 38
249        4.2.1.  Compress Coding  . . . . . . . . . . . . . . . . . . . 38
250        4.2.2.  Deflate Coding . . . . . . . . . . . . . . . . . . . . 38
251        4.2.3.  Gzip Coding  . . . . . . . . . . . . . . . . . . . . . 38
252      4.3.  TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
253      4.4.  Trailer  . . . . . . . . . . . . . . . . . . . . . . . . . 39
254    5.  Message Routing  . . . . . . . . . . . . . . . . . . . . . . . 40
255      5.1.  Identifying a Target Resource  . . . . . . . . . . . . . . 40
256      5.2.  Connecting Inbound . . . . . . . . . . . . . . . . . . . . 40
257      5.3.  Request Target . . . . . . . . . . . . . . . . . . . . . . 41
258        5.3.1.  origin-form  . . . . . . . . . . . . . . . . . . . . . 41
259        5.3.2.  absolute-form  . . . . . . . . . . . . . . . . . . . . 42
260        5.3.3.  authority-form . . . . . . . . . . . . . . . . . . . . 42
261        5.3.4.  asterisk-form  . . . . . . . . . . . . . . . . . . . . 42
262      5.4.  Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
263      5.5.  Effective Request URI  . . . . . . . . . . . . . . . . . . 44
264      5.6.  Associating a Response to a Request  . . . . . . . . . . . 46
265      5.7.  Message Forwarding . . . . . . . . . . . . . . . . . . . . 46
266        5.7.1.  Via  . . . . . . . . . . . . . . . . . . . . . . . . . 47
267        5.7.2.  Transformations  . . . . . . . . . . . . . . . . . . . 48
268    6.  Connection Management  . . . . . . . . . . . . . . . . . . . . 49
269      6.1.  Connection . . . . . . . . . . . . . . . . . . . . . . . . 50
270      6.2.  Establishment  . . . . . . . . . . . . . . . . . . . . . . 51
271      6.3.  Persistence  . . . . . . . . . . . . . . . . . . . . . . . 52
272        6.3.1.  Retrying Requests  . . . . . . . . . . . . . . . . . . 53
273        6.3.2.  Pipelining . . . . . . . . . . . . . . . . . . . . . . 53
274      6.4.  Concurrency  . . . . . . . . . . . . . . . . . . . . . . . 54
275      6.5.  Failures and Timeouts  . . . . . . . . . . . . . . . . . . 54
276      6.6.  Teardown . . . . . . . . . . . . . . . . . . . . . . . . . 55
277      6.7.  Upgrade  . . . . . . . . . . . . . . . . . . . . . . . . . 56
278    7.  ABNF List Extension: #rule . . . . . . . . . . . . . . . . . . 58
279    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 60
280      8.1.  Header Field Registration  . . . . . . . . . . . . . . . . 60
281      8.2.  URI Scheme Registration  . . . . . . . . . . . . . . . . . 60
282      8.3.  Internet Media Type Registration . . . . . . . . . . . . . 61
283        8.3.1.  Internet Media Type message/http . . . . . . . . . . . 61
284        8.3.2.  Internet Media Type application/http . . . . . . . . . 62
285      8.4.  Transfer Coding Registry . . . . . . . . . . . . . . . . . 63
286        8.4.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 63
287        8.4.2.  Registration . . . . . . . . . . . . . . . . . . . . . 64
288      8.5.  Content Coding Registration  . . . . . . . . . . . . . . . 64
289      8.6.  Upgrade Token Registry . . . . . . . . . . . . . . . . . . 65
290        8.6.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 65
291        8.6.2.  Upgrade Token Registration . . . . . . . . . . . . . . 66
292    9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 66
293      9.1.  Establishing Authority . . . . . . . . . . . . . . . . . . 66
294      9.2.  Risks of Intermediaries  . . . . . . . . . . . . . . . . . 67
295      9.3.  Attacks via Protocol Element Length  . . . . . . . . . . . 68
296      9.4.  Response Splitting . . . . . . . . . . . . . . . . . . . . 68
297      9.5.  Request Smuggling  . . . . . . . . . . . . . . . . . . . . 69
298      9.6.  Message Integrity  . . . . . . . . . . . . . . . . . . . . 69
299      9.7.  Message Confidentiality  . . . . . . . . . . . . . . . . . 70
300      9.8.  Privacy of Server Log Information  . . . . . . . . . . . . 70
301    10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 71
302    11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
303      11.1. Normative References . . . . . . . . . . . . . . . . . . . 72
304      11.2. Informative References . . . . . . . . . . . . . . . . . . 74
305    Appendix A.  HTTP Version History  . . . . . . . . . . . . . . . . 76
306      A.1.  Changes from HTTP/1.0  . . . . . . . . . . . . . . . . . . 76
307        A.1.1.  Multihomed Web Servers . . . . . . . . . . . . . . . . 77
308        A.1.2.  Keep-Alive Connections . . . . . . . . . . . . . . . . 77
309        A.1.3.  Introduction of Transfer-Encoding  . . . . . . . . . . 78
310      A.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 78
311    Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 80
312    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
313
314
315Section 1., paragraph 8:
316OLD:
317
318    This HTTP/1.1 specification obsoletes RFC 2616 and RFC 2145 (on HTTP
319    versioning).  This specification also updates the use of CONNECT to
320    establish a tunnel, previously defined in RFC 2817, and defines the
321    "https" URI scheme that was described informally in RFC 2818.
322
323NEW:
324
325    This HTTP/1.1 specification obsoletes [RFC2616] and [RFC2145] (on
326    HTTP versioning).  This specification also updates the use of
327    CONNECT, previously defined in RFC 2817, to establish a tunnel, and
328    defines the "https" URI scheme that was described informally in RFC
329    2818.
330
331
332Section 2.1., paragraph 1:
333OLD:
334
335    HTTP is a stateless request/response protocol that operates by
336    exchanging messages (Section 3) across a reliable transport or
337    session-layer "connection" (Section 6).  An HTTP "client" is a
338    program that establishes a connection to a server for the purpose of
339    sending one or more HTTP requests.  An HTTP "server" is a program
340    that accepts connections in order to service HTTP requests by sending
341    HTTP responses.
342
343NEW:
344
345    HTTP is a stateless request/response protocol that operates by
346    exchanging messages (Section 3) across a reliable transport- or
347    session-layer "connection" (Section 6).  An HTTP "client" is a
348    program that establishes a connection to a server for the purpose of
349    sending one or more HTTP requests.  An HTTP "server" is a program
350    that accepts connections in order to service HTTP requests by sending
351    HTTP responses.
352
353
354Section 2.3., paragraph 7:
355OLD:
356
357    All HTTP requirements applicable to an origin server also apply to
358    the outbound communication of a gateway.  A gateway communicates with
359    inbound servers using any protocol that it desires, including private
360    extensions to HTTP that are outside the scope of this specification.
361    However, an HTTP-to-HTTP gateway that wishes to interoperate with
362    third-party HTTP servers ought to conform to user agent requirements
363    on the gateway's inbound connection.
364
365NEW:
366
367    All HTTP requirements applicable to an origin server also apply to
368    the outbound communication of a gateway.  A gateway communicates with
369    inbound servers using any protocol that it desires, including private
370    extensions to HTTP that are outside the scope of this specification.
371    However, an HTTP-to-HTTP gateway that wishes to interoperate with
372    third-party HTTP servers ought to conform to user-agent requirements
373    on the gateway's inbound connection.
374
375
376Section 2.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 6:
869OLD:
870
871 6.6.  Tear-down
872
873NEW:
874
875 6.6.  Teardown
876
877
878Section 6.5., paragraph 8:
879OLD:
880
881    A client that sends a close connection option MUST NOT send further
882    requests on that connection (after the one containing close) and MUST
883    close the connection after reading the final response message
884    corresponding to this request.
885
886NEW:
887
888    A client that sends a "close" connection option MUST NOT send further
889    requests on that connection (after the one containing close) and MUST
890    close the connection after reading the final response message
891    corresponding to this request.
892
893
894Section 6.5., paragraph 9:
895OLD:
896
897    A server that receives a close connection option MUST initiate a
898    close of the connection (see below) after it sends the final response
899    to the request that contained close.  The server SHOULD send a close
900    connection option in its final response on that connection.  The
901    server MUST NOT process any further requests received on that
902    connection.
903
904NEW:
905
906    A server that receives a "close" connection option MUST initiate a
907    close of the connection (see below) after it sends the final response
908    to the request that contained close.  The server SHOULD send a close
909    connection option in its final response on that connection.  The
910    server MUST NOT process any further requests received on that
911    connection.
912
913
914Section 6.5., paragraph 10:
915OLD:
916
917    A server that sends a close connection option MUST initiate a close
918    of the connection (see below) after it sends the response containing
919    close.  The server MUST NOT process any further requests received on
920    that connection.
921
922NEW:
923
924    A server that sends a "close" connection option MUST initiate a close
925    of the connection (see below) after it sends the response containing
926    close.  The server MUST NOT process any further requests received on
927    that connection.
928
929
930Section 6.5., paragraph 11:
931OLD:
932
933    A client that receives a close connection option MUST cease sending
934    requests on that connection and close the connection after reading
935    the response message containing the close; if additional pipelined
936    requests had been sent on the connection, the client SHOULD NOT
937    assume that they will be processed by the server.
938
939NEW:
940
941    A client that receives a "close" connection option MUST cease sending
942    requests on that connection and close the connection after reading
943    the response message containing the close; if additional pipelined
944    requests had been sent on the connection, the client SHOULD NOT
945    assume that they will be processed by the server.
946
947
948Section 6.7., paragraph 9:
949OLD:
950
951    The capabilities and nature of the application-level communication
952    after the protocol change is entirely dependent upon the new
953    protocol(s) chosen.  However, immediately after sending the 101
954    response, the server is expected to continue responding to the
955    original request as if it had received its equivalent within the new
956    protocol (i.e., the server still has an outstanding request to
957    satisfy after the protocol has been changed, and is expected to do so
958    without requiring the request to be repeated).
959
960NEW:
961
962    The capabilities and nature of the application-level communication
963    after the protocol change is entirely dependent upon the new
964    protocol(s) chosen.  However, immediately after sending the 101
965    (Switching Protocols) response, the server is expected to continue
966    responding to the original request as if it had received its
967    equivalent within the new protocol (i.e., the server still has an
968    outstanding request to satisfy after the protocol has been changed,
969    and is expected to do so without requiring the request to be
970    repeated).
971
972
973Section 7., paragraph 14:
974OLD:
975
976    Then the following are valid values for example-list (not including
977    the double quotes, which are present for delimitation only):
978
979NEW:
980
981    Then, the following are valid values for example-list (not including
982    the double quotes, which are present for delimitation only):
983
984
985Section 8.1., paragraph 1:
986OLD:
987
988    HTTP header fields are registered within the Message Header Field
989    Registry maintained at
990    <http://www.iana.org/assignments/message-headers/>.
991
992NEW:
993
994    HTTP header fields are registered within the "Message Header" field
995    registry maintained at
996    <http://www.iana.org/assignments/message-headers/>.
997
998
999Section 8.1., paragraph 2:
1000OLD:
1001
1002    This document defines the following HTTP header fields, so their
1003    associated registry entries shall be updated according to the
1004    permanent registrations below (see [BCP90]):
1005
1006NEW:
1007
1008    This document defines the following HTTP header fields, so the
1009    "Permanent Message Header Field Names" registry has been updated
1010    accordingly (see [BCP90]).
1011
1012
1013Section 8.1., paragraph 4:
1014OLD:
1015
1016    Furthermore, the header field-name "Close" shall be registered as
1017    "reserved", since using that name as an HTTP header field might
1018    conflict with the "close" connection option of the "Connection"
1019    header field (Section 6.1).
1020
1021NEW:
1022
1023    Furthermore, the header field-name "Close" has been registered as
1024    "reserved", since using that name as an HTTP header field might
1025    conflict with the "close" connection option of the "Connection"
1026    header field (Section 6.1).
1027
1028
1029Section 8.2., paragraph 2:
1030OLD:
1031
1032    This document defines the following URI schemes, so their associated
1033    registry entries shall be updated according to the permanent
1034    registrations below:
1035
1036NEW:
1037
1038    This document defines the following URI schemes, so the "Permanent
1039    URI Schemes" registry has been updated accordingly.
1040
1041
1042Section 8.3., paragraph 2:
1043OLD:
1044
1045    This document serves as the specification for the Internet media
1046    types "message/http" and "application/http".  The following is to be
1047    registered with IANA.
1048
1049NEW:
1050
1051    This document serves as the specification for the Internet media
1052    types "message/http" and "application/http".  The following has been
1053    registered with IANA.
1054
1055
1056Section 8.3.1., paragraph 18:
1057OLD:
1058
1059    Person and email address to contact for further information:  See
1060       Authors' Addresses Section.
1061
1062NEW:
1063
1064    Person and email address to contact for further information:
1065       See Authors' Addresses  Section.
1066
1067
1068Section 8.3.2., paragraph 19:
1069OLD:
1070
1071    Person and email address to contact for further information:  See
1072       Authors' Addresses Section.
1073
1074NEW:
1075
1076    Person and email address to contact for further information:
1077       See Authors' Addresses Section.
1078
1079
1080Section 8.4., paragraph 1:
1081OLD:
1082
1083    The HTTP Transfer Coding Registry defines the namespace for transfer
1084    coding names.  It is maintained at
1085    <http://www.iana.org/assignments/http-parameters>.
1086
1087NEW:
1088
1089    The "HTTP Transfer Coding" registry defines the namespace for
1090    transfer coding names.  It is maintained at
1091    <http://www.iana.org/assignments/http-parameters>.
1092
1093
1094Section 8.4.2., paragraph 1:
1095OLD:
1096
1097    The HTTP Transfer Coding Registry shall be updated with the
1098    registrations below:
1099
1100NEW:
1101
1102    The "HTTP Transfer Coding Registry" has been updated with the
1103    registrations below:
1104
1105
1106Section 8.5., paragraph 1:
1107OLD:
1108
1109    IANA maintains the registry of HTTP Content Codings at
1110    <http://www.iana.org/assignments/http-parameters>.
1111
1112NEW:
1113
1114    IANA maintains the "HTTP Content Coding Registry" at
1115    <http://www.iana.org/assignments/http-parameters>.
1116
1117
1118Section 8.5., paragraph 2:
1119OLD:
1120
1121    The HTTP Content Codings Registry shall be updated with the
1122    registrations below:
1123
1124NEW:
1125
1126    The "HTTP Content Codings Registry" has been updated with the
1127    registrations below:
1128
1129
1130Section 8.6., paragraph 1:
1131OLD:
1132
1133    The HTTP Upgrade Token Registry defines the namespace for protocol-
1134    name tokens used to identify protocols in the Upgrade header field.
1135    The registry is maintained at
1136    <http://www.iana.org/assignments/http-upgrade-tokens>.
1137
1138NEW:
1139
1140    The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
1141    defines the namespace for protocol-name tokens used to identify
1142    protocols in the Upgrade header field.  The registry is maintained at
1143    <http://www.iana.org/assignments/http-upgrade-tokens>.
1144
1145
1146Section 8.6.2., paragraph 1:
1147OLD:
1148
1149    The "HTTP" entry in the HTTP Upgrade Token Registry shall be updated
1150    with the registration below:
1151
1152NEW:
1153
1154    The "HTTP" entry in the "HTTP Upgrade Token" registry shall be
1155    updated with the registration below:
1156
1157
1158Section 9.1., paragraph 3:
1159OLD:
1160
1161    When a registered name is used in the authority component, the "http"
1162    URI scheme (Section 2.7.1) relies on the user's local name resolution
1163    service to determine where it can find authoritative responses.  This
1164    means that any attack on a user's network host table, cached names,
1165    or name resolution libraries becomes an avenue for attack on
1166    establishing authority.  Likewise, the user's choice of server for
1167    Domain Name Service (DNS), and the hierarchy of servers from which it
1168    obtains resolution results, could impact the authenticity of address
1169    mappings; DNS Security Extensions (DNSSEC, [RFC4033]) are one way to
1170    improve authenticity.
1171
1172NEW:
1173
1174    When a registered name is used in the authority component, the "http"
1175    URI scheme (Section 2.7.1) relies on the user's local name resolution
1176    service to determine where it can find authoritative responses.  This
1177    means that any attack on a user's network host table, cached names,
1178    or name resolution libraries becomes an avenue for attack on
1179    establishing authority.  Likewise, the user's choice of server for
1180    Domain Name Service (DNS), and the hierarchy of servers from which it
1181    obtains resolution results, could impact the authenticity of address
1182    mappings; DNS Security Extensions (DNSSEC) ([RFC4033]) is one way to
1183    improve authenticity.
1184
1185
1186Section 9.2., paragraph 1:
1187OLD:
1188
1189    By their very nature, HTTP intermediaries are men-in-the-middle, and
1190    thus represent an opportunity for man-in-the-middle attacks.
1191    Compromise of the systems on which the intermediaries run can result
1192    in serious security and privacy problems.  Intermediaries might have
1193    access to security-related information, personal information about
1194    individual users and organizations, and proprietary information
1195    belonging to users and content providers.  A compromised
1196    intermediary, or an intermediary implemented or configured without
1197    regard to security and privacy considerations, might be used in the
1198    commission of a wide range of potential attacks.
1199
1200NEW:
1201
1202    By their very nature, HTTP intermediaries are men in the middle and,
1203    thus, represent an opportunity for man-in-the-middle attacks.
1204    Compromise of the systems on which the intermediaries run can result
1205    in serious security and privacy problems.  Intermediaries might have
1206    access to security-related information, personal information about
1207    individual users and organizations, and proprietary information
1208    belonging to users and content providers.  A compromised
1209    intermediary, or an intermediary implemented or configured without
1210    regard to security and privacy considerations, might be used in the
1211    commission of a wide range of potential attacks.
1212
1213
1214Section 9.6., paragraph 2:
1215OLD:
1216
1217    User agents are encouraged to implement configurable means for
1218    detecting and reporting failures of message integrity such that those
1219    means can be enabled within environments for which integrity is
1220    necessary.  For example, a browser being used to view medical history
1221    or drug interaction information needs to indicate to the user when
1222    such information is detected by the protocol to be incomplete,
1223    expired, or corrupted during transfer.  Such mechanisms might be
1224    selectively enabled via user agent extensions or the presence of
1225    message integrity metadata in a response.  At a minimum, user agents
1226    ought to provide some indication that allows a user to distinguish
1227    between a complete and incomplete response message (Section 3.4) when
1228    such verification is desired.
1229
1230NEW:
1231
1232    User agents are encouraged to implement configurable means for
1233    detecting and reporting failures of message integrity such that those
1234    means can be enabled within environments for which integrity is
1235    necessary.  For example, a browser being used to view medical history
1236    or drug interaction information needs to indicate to the user when
1237    such information is detected by the protocol to be incomplete,
1238    expired, or corrupted during transfer.  Such mechanisms might be
1239    selectively enabled via user-agent extensions or the presence of
1240    message integrity metadata in a response.  At a minimum, user agents
1241    ought to provide some indication that allows a user to distinguish
1242    between a complete and incomplete response message (Section 3.4) when
1243    such verification is desired.
1244
1245
1246Section 11.1., paragraph 1:
1247OLD:
1248
1249    [RFC0793]     Postel, J., "Transmission Control Protocol", STD 7,
1250                  RFC 793, September 1981.
1251 
1252    [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
1253                  Format Specification version 3.3", RFC 1950, May 1996.
1254
1255NEW:
1256
1257    [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
1258                  Format Specification version 3.3", RFC 1950, May 1996.
1259
1260
1261Section 11.1., paragraph 7:
1262OLD:
1263
1264    [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1265                  Transfer Protocol (HTTP/1.1): Semantics and Content",
1266                  draft-ietf-httpbis-p2-semantics-latest (work in
1267                  progress), May 2014.
1268
1269NEW:
1270
1271    [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1272                  Transfer Protocol (HTTP/1.1): Semantics and Content",
1273                  RFC 7231, May 2014.
1274
1275
1276Section 11.1., paragraph 8:
1277OLD:
1278
1279    [RFC7232]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1280                  Transfer Protocol (HTTP/1.1): Conditional Requests",
1281                  draft-ietf-httpbis-p4-conditional-latest (work in
1282                  progress), May 2014.
1283
1284NEW:
1285
1286    [RFC7232]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1287                  Transfer Protocol (HTTP/1.1): Conditional Requests",
1288                  RFC 7232, May 2014.
1289
1290
1291Section 11.1., paragraph 9:
1292OLD:
1293
1294    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1295                  "Hypertext Transfer Protocol (HTTP/1.1): Range
1296                  Requests", draft-ietf-httpbis-p5-range-latest (work in
1297                  progress), May 2014.
1298
1299NEW:
1300
1301    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1302                  "Hypertext Transfer Protocol (HTTP/1.1): Range
1303                  Requests", RFC 7233, May 2014.
1304
1305
1306Section 11.1., paragraph 10:
1307OLD:
1308
1309    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1310                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1311                  draft-ietf-httpbis-p6-cache-latest (work in progress),
1312                  May 2014.
1313
1314NEW:
1315
1316    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1317                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1318                  RFC 7234, May 2014.
1319
1320
1321Section 11.1., paragraph 11:
1322OLD:
1323
1324    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1325                  Transfer Protocol (HTTP/1.1): Authentication",
1326                  draft-ietf-httpbis-p7-auth-latest (work in progress),
1327                  May 2014.
1328
1329NEW:
1330
1331    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1332                  Transfer Protocol (HTTP/1.1): Authentication",
1333                  RFC 7235, May 2014.
1334 
1335    [RFC793]      Postel, J., "Transmission Control Protocol", STD 7,
1336                  RFC 793, September 1981.
1337
1338
1339Appendix A., paragraph 7:
1340OLD:
1341
1342 A.1.1.  Multi-homed Web Servers
1343
1344NEW:
1345
1346 A.1.1.  Multihomed Web Servers
1347
1348
1349Section 19.7.1, paragraph 8:
1350OLD:
1351
1352    HTTP's approach to error handling has been explained.  (Section 2.5)
1353
1354NEW:
1355
1356    HTTP's approach to error handling has been explained (Section 2.5).
1357
1358
1359Section 19.7.1, paragraph 9:
1360OLD:
1361
1362    The HTTP-version ABNF production has been clarified to be case-
1363    sensitive.  Additionally, version numbers have been restricted to
1364    single digits, due to the fact that implementations are known to
1365    handle multi-digit version numbers incorrectly.  (Section 2.6)
1366
1367NEW:
1368
1369    The HTTP-version ABNF production has been clarified to be case
1370    sensitive.  Additionally, version numbers have been restricted to
1371    single digits, due to the fact that implementations are known to
1372    handle multi-digit version numbers incorrectly (Section 2.6).
1373
1374
1375Section 19.7.1, paragraph 10:
1376OLD:
1377
1378    Userinfo (i.e., username and password) are now disallowed in HTTP and
1379    HTTPS URIs, because of security issues related to their transmission
1380    on the wire.  (Section 2.7.1)
1381
1382NEW:
1383
1384    Userinfo (i.e., username and password) are now disallowed in HTTP and
1385    HTTPS URIs, because of security issues related to their transmission
1386    on the wire (Section 2.7.1).
1387
1388
1389Section 19.7.1, paragraph 11:
1390OLD:
1391
1392    The HTTPS URI scheme is now defined by this specification;
1393    previously, it was done in Section 2.4 of [RFC2818].  Furthermore, it
1394    implies end-to-end security.  (Section 2.7.2)
1395
1396NEW:
1397
1398    The HTTPS URI scheme is now defined by this specification;
1399    previously, it was defined in Section 2.4 of [RFC2818].  Furthermore,
1400    it implies end-to-end security (Section 2.7.2).
1401
1402
1403Section 19.7.1, paragraph 12:
1404OLD:
1405
1406    HTTP messages can be (and often are) buffered by implementations;
1407    despite it sometimes being available as a stream, HTTP is
1408    fundamentally a message-oriented protocol.  Minimum supported sizes
1409    for various protocol elements have been suggested, to improve
1410    interoperability.  (Section 3)
1411
1412NEW:
1413
1414    HTTP messages can be (and often are) buffered by implementations;
1415    despite it sometimes being available as a stream, HTTP is
1416    fundamentally a message-oriented protocol.  Minimum supported sizes
1417    for various protocol elements have been suggested, to improve
1418    interoperability (Section 3).
1419
1420
1421Section 19.7.1, paragraph 13:
1422OLD:
1423
1424    Invalid whitespace around field-names is now required to be rejected,
1425    because accepting it represents a security vulnerability.  The ABNF
1426    productions defining header fields now only list the field value.
1427    (Section 3.2)
1428
1429NEW:
1430
1431    Invalid whitespace around field-names is now required to be rejected,
1432    because accepting it represents a security vulnerability.  The ABNF
1433    productions defining header fields now only list the field value
1434    (Section 3.2).
1435
1436
1437Section 19.7.1, paragraph 14:
1438OLD:
1439
1440    Rules about implicit linear whitespace between certain grammar
1441    productions have been removed; now whitespace is only allowed where
1442    specifically defined in the ABNF.  (Section 3.2.3)
1443
1444NEW:
1445
1446    Rules about implicit linear whitespace between certain grammar
1447    productions have been removed; now whitespace is only allowed where
1448    specifically defined in the ABNF (Section 3.2.3).
1449
1450
1451Section 19.7.1, paragraph 15:
1452OLD:
1453
1454    Header fields that span multiple lines ("line folding") are
1455    deprecated.  (Section 3.2.4)
1456    The NUL octet is no longer allowed in comment and quoted-string text,
1457    and handling of backslash-escaping in them has been clarified.  The
1458    quoted-pair rule no longer allows escaping control characters other
1459    than HTAB.  Non-ASCII content in header fields and the reason phrase
1460    has been obsoleted and made opaque (the TEXT rule was removed).
1461    (Section 3.2.6)
1462
1463NEW:
1464
1465    Header fields that span multiple lines ("line folding") are
1466    deprecated (Section 3.2.4).
1467 
1468    The NUL octet is no longer allowed in comment and quoted-string text,
1469    and handling of backslash-escaping in them has been clarified.  The
1470    quoted-pair rule no longer allows escaping control characters other
1471    than HTAB.  Non-US-ASCII content in header fields and the reason
1472    phrase has been obsoleted and made opaque (the TEXT rule was removed)
1473    (Section 3.2.6).
1474
1475
1476Section 19.7.1, paragraph 16:
1477OLD:
1478
1479    Bogus "Content-Length" header fields are now required to be handled
1480    as errors by recipients.  (Section 3.3.2)
1481
1482NEW:
1483
1484    Bogus "Content-Length" header fields are now required to be handled
1485    as errors by recipients (Section 3.3.2).
1486
1487
1488Section 19.7.1, paragraph 17:
1489OLD:
1490
1491    The algorithm for determining the message body length has been
1492    clarified to indicate all of the special cases (e.g., driven by
1493    methods or status codes) that affect it, and that new protocol
1494    elements cannot define such special cases.  CONNECT is a new, special
1495    case in determining message body length. "multipart/byteranges" is no
1496    longer a way of determining message body length detection.
1497    (Section 3.3.3)
1498
1499NEW:
1500
1501    The algorithm for determining the message body length has been
1502    clarified to indicate all of the special cases (e.g., driven by
1503    methods or status codes) that affect it, and that new protocol
1504    elements cannot define such special cases.  CONNECT is a new, special
1505    case in determining message body length. "multipart/byteranges" is no
1506    longer a way of determining message body length detection
1507    (Section 3.3.3).
1508
1509
1510Section 19.7.1, paragraph 18:
1511OLD:
1512
1513    The "identity" transfer coding token has been removed.  (Sections 3.3
1514    and 4)
1515
1516NEW:
1517
1518    The "identity" transfer coding token has been removed (Sections 3.3
1519    and 4).
1520
1521
1522Section 19.7.1, paragraph 19:
1523OLD:
1524
1525    Chunk length does not include the count of the octets in the chunk
1526    header and trailer.  Line folding in chunk extensions is disallowed.
1527    (Section 4.1)
1528
1529NEW:
1530
1531    Chunk length does not include the count of the octets in the chunk
1532    header and trailer.  Line folding in chunk extensions is disallowed
1533    (Section 4.1).
1534
1535
1536Section 19.7.1, paragraph 20:
1537OLD:
1538
1539    The meaning of the "deflate" content coding has been clarified.
1540    (Section 4.2.2)
1541
1542NEW:
1543
1544    The meaning of the "deflate" content coding has been clarified
1545    (Section 4.2.2).
1546
1547
1548Section 19.7.1, paragraph 21:
1549OLD:
1550
1551    The segment + query components of RFC 3986 have been used to define
1552    the request-target, instead of abs_path from RFC 1808.  The asterisk-
1553    form of the request-target is only allowed with the OPTIONS method.
1554    (Section 5.3)
1555
1556NEW:
1557
1558    The segment + query components of RFC 3986 have been used to define
1559    the request-target, instead of abs_path from RFC 1808.  The asterisk-
1560    form of the request-target is only allowed with the OPTIONS method
1561    (Section 5.3).
1562
1563
1564Section 19.7.1, paragraph 22:
1565OLD:
1566
1567    The term "Effective Request URI" has been introduced.  (Section 5.5)
1568
1569NEW:
1570
1571    The term "Effective Request URI" has been introduced (Section 5.5).
1572
1573
1574Section 19.7.1, paragraph 23:
1575OLD:
1576
1577    Gateways do not need to generate Via header fields anymore.
1578    (Section 5.7.1)
1579
1580NEW:
1581
1582    Gateways do not need to generate Via header fields anymore
1583    (Section 5.7.1).
1584
1585
1586Section 19.7.1, paragraph 24:
1587OLD:
1588
1589    Exactly when "close" connection options have to be sent has been
1590    clarified.  Also, "hop-by-hop" header fields are required to appear
1591    in the Connection header field; just because they're defined as hop-
1592    by-hop in this specification doesn't exempt them.  (Section 6.1)
1593
1594NEW:
1595
1596    Exactly when "close" connection options have to be sent has been
1597    clarified.  Also, "hop-by-hop" header fields are required to appear
1598    in the Connection header field; just because they're defined as hop-
1599    by-hop in this specification doesn't exempt them (Section 6.1).
1600
1601
1602Section 19.7.1, paragraph 25:
1603OLD:
1604
1605    The limit of two connections per server has been removed.  An
1606    idempotent sequence of requests is no longer required to be retried.
1607    The requirement to retry requests under certain circumstances when
1608    the server prematurely closes the connection has been removed.  Also,
1609    some extraneous requirements about when servers are allowed to close
1610    connections prematurely have been removed.  (Section 6.3)
1611
1612NEW:
1613
1614    The limit of two connections per server has been removed.  An
1615    idempotent sequence of requests is no longer required to be retried.
1616    The requirement to retry requests under certain circumstances when
1617    the server prematurely closes the connection has been removed.  Also,
1618    some extraneous requirements about when servers are allowed to close
1619    connections prematurely have been removed (Section 6.3).
1620
1621
1622Section 19.7.1, paragraph 26:
1623OLD:
1624
1625    The semantics of the Upgrade header field is now defined in responses
1626    other than 101 (this was incorporated from [RFC2817]).  Furthermore,
1627    the ordering in the field value is now significant.  (Section 6.7)
1628
1629NEW:
1630
1631    The semantics of the Upgrade header field is now defined in responses
1632    other than 101 (this was incorporated from [RFC2817]).  Furthermore,
1633    the ordering in the field value is now significant (Section 6.7).
1634
1635
1636Section 19.7.1, paragraph 27:
1637OLD:
1638
1639    Empty list elements in list productions (e.g., a list header field
1640    containing ", ,") have been deprecated.  (Section 7)
1641
1642NEW:
1643
1644    Empty list elements in list productions (e.g., a list header field
1645    containing ", ,") have been deprecated (Section 7).
1646
1647
1648Section 19.7.1, paragraph 28:
1649OLD:
1650
1651    Registration of Transfer Codings now requires IETF Review
1652    (Section 8.4)
1653
1654NEW:
1655
1656    Registration of Transfer Codings now requires IETF Review
1657    (Section 8.4).
1658
1659
1660Section 19.7.1, paragraph 29:
1661OLD:
1662
1663    This specification now defines the Upgrade Token Registry, previously
1664    defined in Section 7.2 of [RFC2817].  (Section 8.6)
1665
1666NEW:
1667
1668    This specification now defines the "HTTP Upgrade Tokens" registry,
1669    previously defined in Section 7.2 of [RFC2817] (Section 8.6).
1670
1671
1672Section 19.7.1, paragraph 30:
1673OLD:
1674
1675    The expectation to support HTTP/0.9 requests has been removed.
1676    (Appendix A)
1677
1678NEW:
1679
1680    The expectation to support HTTP/0.9 requests has been removed
1681    (Appendix A).
1682
1683
1684Section 19.7.1, paragraph 31:
1685OLD:
1686
1687    Issues with the Keep-Alive and Proxy-Connection header fields in
1688    requests are pointed out, with use of the latter being discouraged
1689    altogether.  (Appendix A.1.2)
1690
1691NEW:
1692
1693    Issues with the Keep-Alive and Proxy-Connection header fields in
1694    requests are pointed out, with use of the latter being discouraged
1695    altogether (Appendix A.1.2).
1696
1697
1698Appendix B., paragraph 7:
1699OLD:
1700
1701    URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
1702    Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
1703    Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
1704     ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
1705     comment ] ) ] )
1706
1707NEW:
1708
1709    URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
1710    Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
1711 
1712    Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
1713     ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
1714     comment ] ) ] )
1715
1716
1717Appendix B., paragraph 15:
1718OLD:
1719
1720    partial-URI = relative-part [ "?" query ]
1721    path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
1722    port = <port, defined in [RFC3986], Section 3.2.3>
1723    protocol = protocol-name [ "/" protocol-version ]
1724    protocol-name = token
1725    protocol-version = token
1726    pseudonym = token
1727 
1728    qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
1729     / %x5D-7E ; ']'-'~'
1730     / obs-text
1731    query = <query, defined in [RFC3986], Section 3.4>
1732    quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
1733    quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
1734
1735NEW:
1736
1737    partial-URI = relative-part [ "?" query ]
1738    path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
1739    port = <port, defined in [RFC3986], Section 3.2.3>
1740    protocol = protocol-name [ "/" protocol-version ]
1741    protocol-name = token
1742    protocol-version = token
1743    pseudonym = token
1744    qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
1745     / %x5D-7E ; ']'-'~'
1746     / obs-text
1747    query = <query, defined in [RFC3986], Section 3.4>
1748    quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
1749    quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
1750
1751
1752Appendix B., paragraph 24:
1753OLD:
1754
1755    D
1756       deflate (Coding Format)  38
1757       Delimiters  26
1758       downstream  9
1759
1760NEW:
1761
1762    D
1763       deflate (Coding Format)  38
1764       Delimiters  26
1765       downstream  10
1766
1767
1768Appendix B., paragraph 26:
1769OLD:
1770
1771    G
1772       gateway  10
1773       Grammar
1774          absolute-form  41-42
1775          absolute-path  16
1776          absolute-URI  16
1777          ALPHA  6
1778          asterisk-form  41-42
1779          authority  16
1780          authority-form  41-42
1781          BWS  24
1782          chunk  35
1783          chunk-data  35
1784          chunk-ext  35-36
1785          chunk-ext-name  36
1786          chunk-ext-val  36
1787          chunk-size  35
1788          chunked-body  35-36
1789          comment  27
1790          Connection  51
1791          connection-option  51
1792          Content-Length  30
1793          CR  6
1794          CRLF  6
1795          ctext  27
1796          CTL  6
1797          DIGIT  6
1798          DQUOTE  6
1799          field-content  22
1800          field-name  22, 39
1801          field-value  22
1802          field-vchar  22
1803          fragment  16
1804          header-field  22, 36
1805          HEXDIG  6
1806          Host  43
1807          HTAB  6
1808          HTTP-message  19
1809          HTTP-name  13
1810          http-URI  16
1811          HTTP-version  13
1812          https-URI  18
1813          last-chunk  35
1814          LF  6
1815          message-body  27
1816          method  21
1817          obs-fold  22
1818          obs-text  27
1819          OCTET  6
1820          origin-form  41
1821          OWS  24
1822          partial-URI  16
1823          port  16
1824          protocol-name  47
1825          protocol-version  47
1826          pseudonym  47
1827          qdtext  27
1828          query  16
1829          quoted-pair  27
1830          quoted-string  27
1831          rank  38
1832          reason-phrase  22
1833          received-by  47
1834          received-protocol  47
1835          request-line  21
1836          request-target  41
1837          RWS  24
1838          scheme  16
1839          segment  16
1840          SP  6
1841          start-line  20
1842          status-code  22
1843          status-line  22
1844          t-codings  38
1845          t-ranking  38
1846          tchar  27
1847          TE  38
1848          token  27
1849          Trailer  39
1850          trailer-part  35-36
1851          transfer-coding  35
1852          Transfer-Encoding  28
1853          transfer-extension  35
1854          transfer-parameter  35
1855          Upgrade  56
1856          uri-host  16
1857          URI-reference  16
1858          VCHAR  6
1859          Via  47
1860       gzip (Coding Format)  38
1861
1862NEW:
1863
1864    G
1865       gateway  10
1866       Grammar
1867          absolute-form  41-42
1868          absolute-path  16
1869          absolute-URI  16
1870          ALPHA  6
1871          asterisk-form  41-42
1872          authority  16
1873          authority-form  41-42
1874          BWS  24
1875          chunk  35
1876          chunk-data  35
1877          chunk-ext  35-36
1878          chunk-ext-name  36
1879          chunk-ext-val  36
1880          chunk-size  35
1881          chunked-body  35-36
1882          comment  27
1883          Connection  51
1884          connection-option  51
1885          Content-Length  30
1886          CR  6
1887          CRLF  6
1888          ctext  27
1889          CTL  6
1890          DIGIT  6
1891          DQUOTE  6
1892          field-content  22
1893          field-name  22, 39
1894          field-value  22
1895          field-vchar  22
1896          fragment  16
1897          header-field  22, 36
1898          HEXDIG  6
1899          Host  43
1900          HTAB  6
1901          HTTP-message  19
1902          HTTP-name  14
1903          http-URI  16
1904          HTTP-version  14
1905          https-URI  18
1906          last-chunk  35
1907          LF  6
1908          message-body  27
1909          method  21
1910          obs-fold  22
1911          obs-text  27
1912          OCTET  6
1913          origin-form  41
1914          OWS  24
1915          partial-URI  16
1916          port  16
1917          protocol-name  47
1918          protocol-version  47
1919          pseudonym  47
1920          qdtext  27
1921          query  16
1922          quoted-pair  27
1923          quoted-string  27
1924          rank  38
1925          reason-phrase  22
1926          received-by  47
1927          received-protocol  47
1928          request-line  21
1929          request-target  41
1930          RWS  24
1931          scheme  16
1932          segment  16
1933          SP  6
1934          start-line  20
1935          status-code  22
1936          status-line  22
1937          t-codings  38
1938          t-ranking  38
1939          tchar  27
1940          TE  38
1941          token  27
1942          Trailer  39
1943          trailer-part  35-36
1944          transfer-coding  35
1945          Transfer-Encoding  28
1946          transfer-extension  35
1947          transfer-parameter  35
1948          Upgrade  56
1949          uri-host  16
1950          URI-reference  16
1951          VCHAR  6
1952          Via  47
1953       gzip (Coding Format)  38
1954
1955
1956Appendix B., paragraph 28:
1957OLD:
1958
1959    I
1960       inbound  9
1961       interception proxy  11
1962       intermediary  9
1963
1964NEW:
1965
1966    I
1967       inbound  10
1968       interception proxy  11
1969       intermediary  9
1970
1971
1972Appendix B., paragraph 31:
1973OLD:
1974
1975    O
1976       origin server  7
1977       origin-form (of request-target)  41
1978       outbound  9
1979
1980NEW:
1981
1982    O
1983       origin server  7
1984       origin-form (of request-target)  41
1985       outbound  10
1986
1987
1988Appendix B., paragraph 36:
1989OLD:
1990
1991    U
1992       Upgrade header field  56
1993       upstream  9
1994       URI scheme
1995          http  16
1996          https  18
1997       user agent  7
1998
1999NEW:
2000
2001    U
2002       Upgrade header field  56
2003       upstream  10
2004       URI scheme
2005          http  16
2006          https  18
2007       user agent  7
2008
2009
2010Section 345, paragraph 1:
2011OLD:
2012
2013    EMail: fielding@gbiv.com
2014    URI:   http://roy.gbiv.com/
2015 
2016    Julian F. Reschke (editor)
2017    greenbytes GmbH
2018    Hafenweg 16
2019    Muenster, NW  48155
2020    Germany
2021
2022NEW:
2023
2024    EMail: fielding@gbiv.com
2025    URI:   http://roy.gbiv.com/
2026    Julian F. Reschke (editor)
2027    greenbytes GmbH
2028    Hafenweg 16
2029    Muenster, NW  48155
2030    Germany
2031
Note: See TracBrowser for help on using the repository browser.