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

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

"pre-defined" -> "predefined" (#553)

File size: 97.2 KB
Line 
1
2INTRODUCTION, paragraph 1:
3OLD:
4
5 HTTPbis Working Group                                   R. Fielding, Ed.
6 Internet-Draft                                                     Adobe
7 Obsoletes: 2145, 2616                                    J. Reschke, Ed.
8 (if approved)                                                 greenbytes
9 Updates: 2817, 2818 (if approved)                            May 6, 2014
10 Intended status: Standards Track
11 Expires: November 7, 2014
12
13NEW:
14
15 Internet Engineering Task Force (IETF)                  R. Fielding, Ed.
16 Request for Comments: 7230                                         Adobe
17 Obsoletes: 2145, 2616                                    J. Reschke, Ed.
18 Updates: 2817, 2818                                           greenbytes
19 Category: Standards Track                                       May 2014
20 ISSN: 2070-1721
21
22
23INTRODUCTION, paragraph 2:
24OLD:
25
26    Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
27                  draft-ietf-httpbis-p1-messaging-latest
28
29NEW:
30
31    Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
32
33
34INTRODUCTION, paragraph 5:
35OLD:
36
37 Editorial Note (To be removed by RFC Editor)
38 
39    Discussion of this draft takes place on the HTTPBIS working group
40    mailing list (ietf-http-wg@w3.org), which is archived at
41    <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
42 
43    The current issues list is at
44    <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
45    documents (including fancy diffs) can be found at
46    <http://tools.ietf.org/wg/httpbis/>.
47 
48    _This is a temporary document for the purpose of tracking the
49    editorial changes made during the AUTH48 (RFC publication) phase._
50 
51 Status of This Memo
52
53NEW:
54
55 Status of This Memo
56
57
58INTRODUCTION, paragraph 6:
59OLD:
60
61    This Internet-Draft is submitted in full conformance with the
62    provisions of BCP 78 and BCP 79.
63 
64    Internet-Drafts are working documents of the Internet Engineering
65    Task Force (IETF).  Note that other groups may also distribute
66    working documents as Internet-Drafts.  The list of current Internet-
67    Drafts is at http://datatracker.ietf.org/drafts/current/.
68
69NEW:
70
71    This is an Internet Standards Track document.
72
73
74INTRODUCTION, paragraph 7:
75OLD:
76
77    Internet-Drafts are draft documents valid for a maximum of six months
78    and may be updated, replaced, or obsoleted by other documents at any
79    time.  It is inappropriate to use Internet-Drafts as reference
80    material or to cite them other than as "work in progress."
81
82NEW:
83
84    This document is a product of the Internet Engineering Task Force
85    (IETF).  It represents the consensus of the IETF community.  It has
86    received public review and has been approved for publication by the
87    Internet Engineering Steering Group (IESG).  Further information on
88    Internet Standards is available in Section 2 of RFC 5741.
89
90
91INTRODUCTION, paragraph 8:
92OLD:
93
94    This Internet-Draft will expire on November 7, 2014.
95
96NEW:
97
98    Information about the current status of this document, any errata,
99    and how to provide feedback on it may be obtained at
100    http://www.rfc-editor.org/info/rfc7230.
101
102
103Section 11., paragraph 0:
104OLD:
105
106    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
107      1.1.  Requirements Notation  . . . . . . . . . . . . . . . . . .  6
108      1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  6
109    2.  Architecture . . . . . . . . . . . . . . . . . . . . . . . . .  6
110      2.1.  Client/Server Messaging  . . . . . . . . . . . . . . . . .  7
111      2.2.  Implementation Diversity . . . . . . . . . . . . . . . . .  8
112      2.3.  Intermediaries . . . . . . . . . . . . . . . . . . . . . .  9
113      2.4.  Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11
114      2.5.  Conformance and Error Handling . . . . . . . . . . . . . . 12
115      2.6.  Protocol Versioning  . . . . . . . . . . . . . . . . . . . 13
116      2.7.  Uniform Resource Identifiers . . . . . . . . . . . . . . . 16
117        2.7.1.  http URI Scheme  . . . . . . . . . . . . . . . . . . . 16
118        2.7.2.  https URI Scheme . . . . . . . . . . . . . . . . . . . 18
119        2.7.3.  http and https URI Normalization and Comparison  . . . 19
120 
121    3.  Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19
122      3.1.  Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20
123        3.1.1.  Request Line . . . . . . . . . . . . . . . . . . . . . 21
124        3.1.2.  Status Line  . . . . . . . . . . . . . . . . . . . . . 22
125      3.2.  Header Fields  . . . . . . . . . . . . . . . . . . . . . . 22
126        3.2.1.  Field Extensibility  . . . . . . . . . . . . . . . . . 23
127        3.2.2.  Field Order  . . . . . . . . . . . . . . . . . . . . . 23
128        3.2.3.  Whitespace . . . . . . . . . . . . . . . . . . . . . . 24
129        3.2.4.  Field Parsing  . . . . . . . . . . . . . . . . . . . . 25
130        3.2.5.  Field Limits . . . . . . . . . . . . . . . . . . . . . 26
131        3.2.6.  Field Value Components . . . . . . . . . . . . . . . . 26
132      3.3.  Message Body . . . . . . . . . . . . . . . . . . . . . . . 27
133        3.3.1.  Transfer-Encoding  . . . . . . . . . . . . . . . . . . 28
134        3.3.2.  Content-Length . . . . . . . . . . . . . . . . . . . . 30
135        3.3.3.  Message Body Length  . . . . . . . . . . . . . . . . . 31
136      3.4.  Handling Incomplete Messages . . . . . . . . . . . . . . . 33
137      3.5.  Message Parsing Robustness . . . . . . . . . . . . . . . . 34
138    4.  Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 35
139      4.1.  Chunked Transfer Coding  . . . . . . . . . . . . . . . . . 35
140        4.1.1.  Chunk Extensions . . . . . . . . . . . . . . . . . . . 36
141        4.1.2.  Chunked Trailer Part . . . . . . . . . . . . . . . . . 36
142        4.1.3.  Decoding Chunked . . . . . . . . . . . . . . . . . . . 37
143      4.2.  Compression Codings  . . . . . . . . . . . . . . . . . . . 38
144        4.2.1.  Compress Coding  . . . . . . . . . . . . . . . . . . . 38
145        4.2.2.  Deflate Coding . . . . . . . . . . . . . . . . . . . . 38
146        4.2.3.  Gzip Coding  . . . . . . . . . . . . . . . . . . . . . 38
147      4.3.  TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
148      4.4.  Trailer  . . . . . . . . . . . . . . . . . . . . . . . . . 39
149    5.  Message Routing  . . . . . . . . . . . . . . . . . . . . . . . 40
150      5.1.  Identifying a Target Resource  . . . . . . . . . . . . . . 40
151      5.2.  Connecting Inbound . . . . . . . . . . . . . . . . . . . . 40
152      5.3.  Request Target . . . . . . . . . . . . . . . . . . . . . . 41
153        5.3.1.  origin-form  . . . . . . . . . . . . . . . . . . . . . 41
154        5.3.2.  absolute-form  . . . . . . . . . . . . . . . . . . . . 42
155        5.3.3.  authority-form . . . . . . . . . . . . . . . . . . . . 42
156        5.3.4.  asterisk-form  . . . . . . . . . . . . . . . . . . . . 42
157      5.4.  Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
158      5.5.  Effective Request URI  . . . . . . . . . . . . . . . . . . 44
159      5.6.  Associating a Response to a Request  . . . . . . . . . . . 46
160      5.7.  Message Forwarding . . . . . . . . . . . . . . . . . . . . 46
161        5.7.1.  Via  . . . . . . . . . . . . . . . . . . . . . . . . . 47
162        5.7.2.  Transformations  . . . . . . . . . . . . . . . . . . . 48
163    6.  Connection Management  . . . . . . . . . . . . . . . . . . . . 49
164      6.1.  Connection . . . . . . . . . . . . . . . . . . . . . . . . 50
165      6.2.  Establishment  . . . . . . . . . . . . . . . . . . . . . . 51
166      6.3.  Persistence  . . . . . . . . . . . . . . . . . . . . . . . 52
167        6.3.1.  Retrying Requests  . . . . . . . . . . . . . . . . . . 53
168        6.3.2.  Pipelining . . . . . . . . . . . . . . . . . . . . . . 53
169 
170      6.4.  Concurrency  . . . . . . . . . . . . . . . . . . . . . . . 54
171      6.5.  Failures and Time-outs . . . . . . . . . . . . . . . . . . 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.1., paragraph 2:
355OLD:
356
357    The terms client and server refer only to the roles that these
358    programs perform for a particular connection.  The same program might
359    act as a client on some connections and a server on others.  The term
360    "user agent" refers to any of the various client programs that
361    initiate a request, including (but not limited to) browsers, spiders
362    (web-based robots), command-line tools, custom applications, and
363    mobile apps.  The term "origin server" refers to the program that can
364    originate authoritative responses for a given target resource.  The
365    terms "sender" and "recipient" refer to any implementation that sends
366    or receives a given message, respectively.
367
368NEW:
369
370    The terms "client" and "server" refer only to the roles that these
371    programs perform for a particular connection.  The same program might
372    act as a client on some connections and a server on others.  The term
373    "user agent" refers to any of the various client programs that
374    initiate a request, including (but not limited to) browsers, spiders
375    (web-based robots), command-line tools, custom applications, and
376    mobile apps.  The term "origin server" refers to the program that can
377    originate authoritative responses for a given target resource.  The
378    terms "sender" and "recipient" refer to any implementation that sends
379    or receives a given message, respectively.
380
381
382Section 2.2., paragraph 1:
383OLD:
384
385    When considering the design of HTTP, it is easy to fall into a trap
386    of thinking that all user agents are general-purpose browsers and all
387    origin servers are large public websites.  That is not the case in
388    practice.  Common HTTP user agents include household appliances,
389    stereos, scales, firmware update scripts, command-line programs,
390    mobile apps, and communication devices in a multitude of shapes and
391    sizes.  Likewise, common HTTP origin servers include home automation
392    units, configurable networking components, office machines,
393    autonomous robots, news feeds, traffic cameras, ad selectors, and
394    video delivery platforms.
395
396NEW:
397
398    When considering the design of HTTP, it is easy to fall into a trap
399    of thinking that all user agents are general-purpose browsers and all
400    origin servers are large public websites.  That is not the case in
401    practice.  Common HTTP user agents include household appliances,
402    stereos, scales, firmware update scripts, command-line programs,
403    mobile apps, and communication devices in a multitude of shapes and
404    sizes.  Likewise, common HTTP origin servers include home automation
405    units, configurable networking components, office machines,
406    autonomous robots, news feeds, traffic cameras, ad selectors, and
407    video-delivery platforms.
408
409
410Section 2.3., paragraph 3:
411OLD:
412
413    The figure above shows three intermediaries (A, B, and C) between the
414    user agent and origin server.  A request or response message that
415    travels the whole chain will pass through four separate connections.
416    Some HTTP communication options might apply only to the connection
417    with the nearest, non-tunnel neighbor, only to the end-points of the
418    chain, or to all connections along the chain.  Although the diagram
419    is linear, each participant might be engaged in multiple,
420    simultaneous communications.  For example, B might be receiving
421    requests from many clients other than A, and/or forwarding requests
422    to servers other than C, at the same time that it is handling A's
423    request.  Likewise, later requests might be sent through a different
424    path of connections, often based on dynamic configuration for load
425    balancing.
426
427NEW:
428
429    The figure above shows three intermediaries (A, B, and C) between the
430    user agent and origin server.  A request or response message that
431    travels the whole chain will pass through four separate connections.
432    Some HTTP communication options might apply only to the connection
433    with the nearest, non-tunnel neighbor, only to the endpoints of the
434    chain, or to all connections along the chain.  Although the diagram
435    is linear, each participant might be engaged in multiple,
436    simultaneous communications.  For example, B might be receiving
437    requests from many clients other than A, and/or forwarding requests
438    to servers other than C, at the same time that it is handling A's
439    request.  Likewise, later requests might be sent through a different
440    path of connections, often based on dynamic configuration for load
441    balancing.
442
443
444Section 2.3., paragraph 4:
445OLD:
446
447    The terms "upstream" and "downstream" are used to describe
448    directional requirements in relation to the message flow: all
449    messages flow from upstream to downstream.  The terms inbound and
450    outbound are used to describe directional requirements in relation to
451    the request route: "inbound" means toward the origin server and
452    "outbound" means toward the user agent.
453
454NEW:
455
456    The terms "upstream" and "downstream" are used to describe
457    directional requirements in relation to the message flow: all
458    messages flow from upstream to downstream.  The terms "inbound" and
459    "outbound" are used to describe directional requirements in relation
460    to the request route: "inbound" means toward the origin server and
461    "outbound" means toward the user agent.
462
463
464Section 2.3., paragraph 5:
465OLD:
466
467    A "proxy" is a message forwarding agent that is selected by the
468    client, usually via local configuration rules, to receive requests
469    for some type(s) of absolute URI and attempt to satisfy those
470    requests via translation through the HTTP interface.  Some
471    translations are minimal, such as for proxy requests for "http" URIs,
472    whereas other requests might require translation to and from entirely
473    different application-level protocols.  Proxies are often used to
474    group an organization's HTTP requests through a common intermediary
475    for the sake of security, annotation services, or shared caching.
476    Some proxies are designed to apply transformations to selected
477    messages or payloads while they are being forwarded, as described in
478    Section 5.7.2.
479
480NEW:
481
482    A "proxy" is a message-forwarding agent that is selected by the
483    client, usually via local configuration rules, to receive requests
484    for some type(s) of absolute URI and attempt to satisfy those
485    requests via translation through the HTTP interface.  Some
486    translations are minimal, such as for proxy requests for "http" URIs,
487    whereas other requests might require translation to and from entirely
488    different application-level protocols.  Proxies are often used to
489    group an organization's HTTP requests through a common intermediary
490    for the sake of security, annotation services, or shared caching.
491    Some proxies are designed to apply transformations to selected
492    messages or payloads while they are being forwarded, as described in
493    Section 5.7.2.
494
495
496Section 2.3., paragraph 7:
497OLD:
498
499    All HTTP requirements applicable to an origin server also apply to
500    the outbound communication of a gateway.  A gateway communicates with
501    inbound servers using any protocol that it desires, including private
502    extensions to HTTP that are outside the scope of this specification.
503    However, an HTTP-to-HTTP gateway that wishes to interoperate with
504    third-party HTTP servers ought to conform to user agent requirements
505    on the gateway's inbound connection.
506
507NEW:
508
509    All HTTP requirements applicable to an origin server also apply to
510    the outbound communication of a gateway.  A gateway communicates with
511    inbound servers using any protocol that it desires, including private
512    extensions to HTTP that are outside the scope of this specification.
513    However, an HTTP-to-HTTP gateway that wishes to interoperate with
514    third-party HTTP servers ought to conform to user-agent requirements
515    on the gateway's inbound connection.
516
517
518Section 2.3., paragraph 11:
519OLD:
520
521    HTTP is defined as a stateless protocol, meaning that each request
522    message can be understood in isolation.  Many implementations depend
523    on HTTP's stateless design in order to reuse proxied connections or
524    dynamically load-balance requests across multiple servers.  Hence, a
525    server MUST NOT assume that two requests on the same connection are
526    from the same user agent unless the connection is secured and
527    specific to that agent.  Some non-standard HTTP extensions (e.g.,
528    [RFC4559]) have been known to violate this requirement, resulting in
529    security and interoperability problems.
530
531NEW:
532
533    HTTP is defined as a stateless protocol, meaning that each request
534    message can be understood in isolation.  Many implementations depend
535    on HTTP's stateless design in order to reuse proxied connections or
536    dynamically load balance requests across multiple servers.  Hence, a
537    server MUST NOT assume that two requests on the same connection are
538    from the same user agent unless the connection is secured and
539    specific to that agent.  Some non-standard HTTP extensions (e.g.,
540    [RFC4559]) have been known to violate this requirement, resulting in
541    security and interoperability problems.
542
543
544Section 2.4., paragraph 5:
545OLD:
546
547    There are a wide variety of architectures and configurations of
548    caches deployed across the World Wide Web and inside large
549    organizations.  These include national hierarchies of proxy caches to
550    save transoceanic bandwidth, collaborative systems that broadcast or
551    multicast cache entries, archives of pre-fetched cache entries for
552    use in off-line or high-latency environments, and so on.
553
554NEW:
555
556    There is a wide variety of architectures and configurations of caches
557    deployed across the World Wide Web and inside large organizations.
558    These include national hierarchies of proxy caches to save
559    transoceanic bandwidth, collaborative systems that broadcast or
560    multicast cache entries, archives of pre-fetched cache entries for
561    use in off-line or high-latency environments, and so on.
562
563
564Section 2.5., paragraph 5:
565OLD:
566
567    When a received protocol element is parsed, the recipient MUST be
568    able to parse any value of reasonable length that is applicable to
569    the recipient's role and matches the grammar defined by the
570    corresponding ABNF rules.  Note, however, that some received protocol
571    elements might not be parsed.  For example, an intermediary
572    forwarding a message might parse a header-field into generic field-
573    name and field-value components, but then forward the header field
574    without further parsing inside the field-value.
575
576NEW:
577
578    When a received protocol element is parsed, the recipient MUST be
579    able to parse any value of reasonable length that is applicable to
580    the recipient's role and that matches the grammar defined by the
581    corresponding ABNF rules.  Note, however, that some received protocol
582    elements might not be parsed.  For example, an intermediary
583    forwarding a message might parse a header-field into generic field-
584    name and field-value components, but then forward the header field
585    without further parsing inside the field-value.
586
587
588Section 2.6., paragraph 2:
589OLD:
590
591    The version of an HTTP message is indicated by an HTTP-version field
592    in the first line of the message.  HTTP-version is case-sensitive.
593
594NEW:
595
596    The version of an HTTP message is indicated by an HTTP-version field
597    in the first line of the message.  HTTP-version is case sensitive.
598
599
600Section 2.6., paragraph 3:
601OLD:
602
603      HTTP-version  = HTTP-name "/" DIGIT "." DIGIT
604      HTTP-name     = %x48.54.54.50 ; "HTTP", case-sensitive
605
606NEW:
607
608      HTTP-version  = HTTP-name "/" DIGIT "." DIGIT
609      HTTP-name     = %x48.54.54.50 ; "HTTP", case sensitive
610
611
612Section 2.6., paragraph 7:
613OLD:
614
615    New header fields can be introduced without changing the protocol
616    version if their defined semantics allow them to be safely ignored by
617    recipients that do not recognize them.  Header field extensibility is
618    discussed in Section 3.2.1.
619
620NEW:
621
622    New header fields can be introduced without changing the protocol
623    version if their defined semantics allow them to be safely ignored by
624    recipients that do not recognize them.  Header-field extensibility is
625    discussed in Section 3.2.1.
626
627
628Section 2.6., paragraph 14:
629OLD:
630
631    When an HTTP message is received with a major version number that the
632    recipient implements, but a higher minor version number than what the
633    recipient implements, the recipient SHOULD process the message as if
634    it were in the highest minor version within that major version to
635    which the recipient is conformant.  A recipient can assume that a
636    message with a higher minor version, when sent to a recipient that
637    has not yet indicated support for that higher version, is
638    sufficiently backwards-compatible to be safely processed by any
639    implementation of the same major version.
640
641NEW:
642
643    When an HTTP message is received with a major version number that the
644    recipient implements, but a higher minor version number than what the
645    recipient implements, the recipient SHOULD process the message as if
646    it were in the highest minor version within that major version to
647    which the recipient is conformant.  A recipient can assume that a
648    message with a higher minor version, when sent to a recipient that
649    has not yet indicated support for that higher version, is
650    sufficiently backwards compatible to be safely processed by any
651    implementation of the same major version.
652
653
654Section 2.7., paragraph 2:
655OLD:
656
657    The definitions of "URI-reference", "absolute-URI", "relative-part",
658    "scheme", "authority", "port", "host", "path-abempty", "segment",
659    "query", and "fragment" are adopted from the URI generic syntax.  An
660    "absolute-path" rule is defined for protocol elements that can
661    contain a non-empty path component.  (This rule differs slightly from
662    RFC 3986's path-abempty rule, which allows for an empty path to be
663    used in references, and path-absolute rule, which does not allow
664    paths that begin with "//".)  A "partial-URI" rule is defined for
665    protocol elements that can contain a relative URI but not a fragment
666    component.
667
668NEW:
669
670    The definitions of "URI-reference", "absolute-URI", "relative-part",
671    "scheme", "authority", "port", "host", "path-abempty", "segment",
672    "query", and "fragment" are adopted from the URI generic syntax.  An
673    "absolute-path" rule is defined for protocol elements that can
674    contain a non-empty path component.  (This rule differs slightly from
675    the path-abempty rule of RFC 3986, which allows for an empty path to
676    be used in references, and path-absolute rule, which does not allow
677    paths that begin with "//".)  A "partial-URI" rule is defined for
678    protocol elements that can contain a relative URI but not a fragment
679    component.
680
681
682Section 2.7.1., paragraph 1:
683OLD:
684
685    The "http" URI scheme is hereby defined for the purpose of minting
686    identifiers according to their association with the hierarchical
687    namespace governed by a potential HTTP origin server listening for
688    TCP ([RFC0793]) connections on a given port.
689
690NEW:
691
692    The "http" URI scheme is hereby defined for the purpose of minting
693    identifiers according to their association with the hierarchical
694    namespace governed by a potential HTTP origin server listening for
695    TCP ([RFC793]) connections on a given port.
696
697
698Section 2.1, paragraph 0:
699OLD:
700
701    If the port is equal to the default port for a scheme, the normal
702    form is to omit the port subcomponent.  When not being used in
703    absolute form as the request target of an OPTIONS request, an empty
704    path component is equivalent to an absolute path of "/", so the
705    normal form is to provide a path of "/" instead.  The scheme and host
706    are case-insensitive and normally provided in lowercase; all other
707    components are compared in a case-sensitive manner.  Characters other
708    than those in the "reserved" set are equivalent to their percent-
709    encoded octets: the normal form is to not encode them (see Sections
710    2.1 and 2.2 of [RFC3986]).
711
712NEW:
713
714    If the port is equal to the default port for a scheme, the normal
715    form is to omit the port subcomponent.  When not being used in
716    absolute form as the request target of an OPTIONS request, an empty
717    path component is equivalent to an absolute path of "/", so the
718    normal form is to provide a path of "/" instead.  The scheme and host
719    are case insensitive and normally provided in lowercase; all other
720    components are compared in a case-sensitive manner.  Characters other
721    than those in the "reserved" set are equivalent to their percent-
722    encoded octets: the normal form is to not encode them (see Sections
723    2.1 and 2.2 of [RFC3986]).
724
725
726Section 3.1., paragraph 1:
727OLD:
728
729    An HTTP message can either be a request from client to server or a
730    response from server to client.  Syntactically, the two types of
731    message differ only in the start-line, which is either a request-line
732    (for requests) or a status-line (for responses), and in the algorithm
733    for determining the length of the message body (Section 3.3).
734
735NEW:
736
737    An HTTP message can be either a request from client to server or a
738    response from server to client.  Syntactically, the two types of
739    message differ only in the start-line, which is either a request-line
740    (for requests) or a status-line (for responses), and in the algorithm
741    for determining the length of the message body (Section 3.3).
742
743
744Section 3.1., paragraph 2:
745OLD:
746
747    In theory, a client could receive requests and a server could receive
748    responses, distinguishing them by their different start-line formats,
749    but, in practice, servers are implemented to only expect a request (a
750    response is interpreted as an unknown or invalid request method) and
751    clients are implemented to only expect a response.
752
753NEW:
754
755    In theory, a client could receive requests and a server could receive
756    responses, distinguishing them by their different start-line formats,
757    but, in practice, servers are implemented only to expect a request (a
758    response is interpreted as an unknown or invalid request method) and
759    clients are implemented to only expect a response.
760
761
762Section 3.1.1., paragraph 1:
763OLD:
764
765    A request-line begins with a method token, followed by a single space
766    (SP), the request-target, another single space (SP), the protocol
767    version, and ending with CRLF.
768
769NEW:
770
771    A request-line begins with a method token and is followed by a single
772    space (SP), the request-target, another single space (SP), the
773    protocol version, and ends with CRLF.
774
775
776Section 3.1.1., paragraph 3:
777OLD:
778
779    The method token indicates the request method to be performed on the
780    target resource.  The request method is case-sensitive.
781
782NEW:
783
784    The method token indicates the request method to be performed on the
785    target resource.  The request method is case sensitive.
786
787
788Section 3.1.2., paragraph 1:
789OLD:
790
791    The first line of a response message is the status-line, consisting
792    of the protocol version, a space (SP), the status code, another
793    space, a possibly-empty textual phrase describing the status code,
794    and ending with CRLF.
795
796NEW:
797
798    The first line of a response message is the status-line, consisting
799    of the protocol version, a space (SP), the status code, another space
800    (SP), a possibly empty textual phrase describing the status code,
801    and, finally, CRLF.
802
803
804Section 3.2.1., paragraph 4:
805OLD:
806
807    All defined header fields ought to be registered with IANA in the
808    Message Header Field Registry, as described in Section 8.3 of
809    [RFC7231].
810
811NEW:
812
813    All defined header fields ought to be registered with IANA in the
814    "Message Headers" field registry, as described in Section 8.3 of
815    [RFC7231].
816
817
818Section 3.2.2., paragraph 4:
819OLD:
820
821       Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
822       appears multiple times in a response message and does not use the
823       list syntax, violating the above requirements on multiple header
824       fields with the same name.  Since it cannot be combined into a
825       single field-value, recipients ought to handle "Set-Cookie" as a
826       special case while processing header fields.  (See Appendix A.2.3
827       of [Kri2001] for details.)
828
829NEW:
830
831       Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
832       appears multiple times in a response message and does not use the
833       list syntax, violating the above requirements on multiple header
834       fields with the same name.  Since it cannot be combined into a
835       single field-value, recipients ought to handle Set-Cookie as a
836       special case while processing header fields.  (See Appendix A.2.3
837       of [Kri2001] for details.)
838
839
840Section 3.2.3., paragraph 2:
841OLD:
842
843    The OWS rule is used where zero or more linear whitespace octets
844    might appear.  For protocol elements where optional whitespace is
845    preferred to improve readability, a sender SHOULD generate the
846    optional whitespace as a single SP; otherwise, a sender SHOULD NOT
847    generate optional whitespace except as needed to white-out invalid or
848    unwanted protocol elements during in-place message filtering.
849
850NEW:
851
852    The OWS rule is used where zero or more linear whitespace octets
853    might appear.  For protocol elements where optional whitespace is
854    preferred to improve readability, a sender SHOULD generate the
855    optional whitespace as a single SP; otherwise, a sender SHOULD NOT
856    generate optional whitespace except as needed to white out invalid or
857    unwanted protocol elements during in-place message filtering.
858
859
860Section 3.2.4., paragraph 1:
861OLD:
862
863    Messages are parsed using a generic algorithm, independent of the
864    individual header field names.  The contents within a given field
865    value are not parsed until a later stage of message interpretation
866    (usually after the message's entire header section has been
867    processed).  Consequently, this specification does not use ABNF rules
868    to define each "Field-Name: Field Value" pair, as was done in
869    previous editions.  Instead, this specification uses ABNF rules which
870    are named according to each registered field name, wherein the rule
871    defines the valid grammar for that field's corresponding field values
872    (i.e., after the field-value has been extracted from the header
873    section by a generic field parser).
874
875NEW:
876
877    Messages are parsed using a generic algorithm, independent of the
878    individual header field names.  The contents within a given field
879    value are not parsed until a later stage of message interpretation
880    (usually after the message's entire header section has been
881    processed).  Consequently, this specification does not use ABNF rules
882    to define each "field-name: field-value" pair, as was done in
883    previous editions.  Instead, this specification uses ABNF rules that
884    are named according to each registered field name, wherein the rule
885    defines the valid grammar for that field's corresponding field values
886    (i.e., after the field-value has been extracted from the header
887    section by a generic field parser).
888
889
890Section 3.2.4., paragraph 8:
891OLD:
892
893    Historically, HTTP has allowed field content with text in the ISO-
894    8859-1 [ISO-8859-1] charset, supporting other charsets only through
895    use of [RFC2047] encoding.  In practice, most HTTP header field
896    values use only a subset of the US-ASCII charset [USASCII].  Newly
897    defined header fields SHOULD limit their field values to US-ASCII
898    octets.  A recipient SHOULD treat other octets in field content (obs-
899    text) as opaque data.
900
901NEW:
902
903    Historically, HTTP has allowed field content with text in the
904    ISO-8859-1 [ISO-8859-1] charset, supporting other charsets only
905    through use of [RFC2047] encoding.  In practice, most HTTP header
906    field values use only a subset of the US-ASCII charset [USASCII].
907    Newly defined header fields SHOULD limit their field values to
908    US-ASCII octets.  A recipient SHOULD treat other octets in field
909    content (obs-text) as opaque data.
910
911
912Section 7., paragraph 1:
913OLD:
914
915    Since there is no way to distinguish a successfully completed, close-
916    delimited message from a partially-received message interrupted by
917    network failure, a server SHOULD generate encoding or length-
918    delimited messages whenever possible.  The close-delimiting feature
919    exists primarily for backwards compatibility with HTTP/1.0.
920
921NEW:
922
923    Since there is no way to distinguish a successfully completed, close-
924    delimited message from a partially received message interrupted by
925    network failure, a server SHOULD generate encoding or length-
926    delimited messages whenever possible.  The close-delimiting feature
927    exists primarily for backwards compatibility with HTTP/1.0.
928
929
930Section 3.4., paragraph 1:
931OLD:
932
933    A server that receives an incomplete request message, usually due to
934    a canceled request or a triggered time-out exception, MAY send an
935    error response prior to closing the connection.
936
937NEW:
938
939    A server that receives an incomplete request message, usually due to
940    a canceled request or a triggered timeout exception, MAY send an
941    error response prior to closing the connection.
942
943
944Section 4., paragraph 5:
945OLD:
946
947    All transfer-coding names are case-insensitive and ought to be
948    registered within the HTTP Transfer Coding registry, as defined in
949    Section 8.4.  They are used in the TE (Section 4.3) and Transfer-
950    Encoding (Section 3.3.1) header fields.
951
952NEW:
953
954    All transfer-coding names are case insensitive and ought to be
955    registered within the "HTTP Transfer Coding" registry, as defined in
956    Section 8.4.  They are used in the TE (Section 4.3) and Transfer-
957    Encoding (Section 3.3.1) header fields.
958
959
960Section 4.2.3., paragraph 1:
961OLD:
962
963    The "gzip" coding is an LZ77 coding with a 32 bit CRC that is
964    commonly produced by the gzip file compression program [RFC1952].  A
965    recipient SHOULD consider "x-gzip" to be equivalent to "gzip".
966
967NEW:
968
969    The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy
970    Check (CRC) that is commonly produced by the gzip file compression
971    program [RFC1952].  A recipient SHOULD consider "x-gzip" to be
972    equivalent to "gzip".
973
974
975Section 5.7.2., paragraph 6:
976OLD:
977
978    A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of
979    a message that contains a no-transform cache-control directive
980    (Section 5.2 of [RFC7234]).
981
982NEW:
983
984    A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of
985    a message that contains a no-transform Cache-Control directive
986    (Section 5.2 of [RFC7234]).
987
988
989Section 200, paragraph 0:
990OLD:
991
992    A proxy MAY transform the payload of a message that does not contain
993    a no-transform cache-control directive.  A proxy that transforms a
994    payload MUST add a Warning header field with the warn-code of 214
995    ("Transformation Applied") if one is not already in the message (see
996    Section 5.5 of [RFC7234]).  A proxy that transforms the payload of a
997    200 (OK) response can further inform downstream recipients that a
998    transformation has been applied by changing the response status code
999    to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).
1000
1001NEW:
1002
1003    A proxy MAY transform the payload of a message that does not contain
1004    a no-transform Cache-Control directive.  A proxy that transforms a
1005    payload MUST add a Warning header field with the warn-code of 214
1006    ("Transformation Applied") if one is not already in the message (see
1007    Section 5.5 of [RFC7234]).  A proxy that transforms the payload of a
1008    200 (OK) response can further inform downstream recipients that a
1009    transformation has been applied by changing the response status code
1010    to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).
1011
1012
1013Section 6., paragraph 1:
1014OLD:
1015
1016    HTTP messaging is independent of the underlying transport or session-
1017    layer connection protocol(s).  HTTP only presumes a reliable
1018    transport with in-order delivery of requests and the corresponding
1019    in-order delivery of responses.  The mapping of HTTP request and
1020    response structures onto the data units of an underlying transport
1021    protocol is outside the scope of this specification.
1022
1023NEW:
1024
1025    HTTP messaging is independent of the underlying transport- or
1026    session-layer connection protocol(s).  HTTP only presumes a reliable
1027    transport with in-order delivery of requests and the corresponding
1028    in-order delivery of responses.  The mapping of HTTP request and
1029    response structures onto the data units of an underlying transport
1030    protocol is outside the scope of this specification.
1031
1032
1033Section 6., paragraph 3:
1034OLD:
1035
1036    HTTP implementations are expected to engage in connection management,
1037    which includes maintaining the state of current connections,
1038    establishing a new connection or reusing an existing connection,
1039    processing messages received on a connection, detecting connection
1040    failures, and closing each connection.  Most clients maintain
1041    multiple connections in parallel, including more than one connection
1042    per server endpoint.  Most servers are designed to maintain thousands
1043    of concurrent connections, while controlling request queues to enable
1044    fair use and detect denial of service attacks.
1045
1046NEW:
1047
1048    HTTP implementations are expected to engage in connection management,
1049    which includes maintaining the state of current connections,
1050    establishing a new connection or reusing an existing connection,
1051    processing messages received on a connection, detecting connection
1052    failures, and closing each connection.  Most clients maintain
1053    multiple connections in parallel, including more than one connection
1054    per server endpoint.  Most servers are designed to maintain thousands
1055    of concurrent connections, while controlling request queues to enable
1056    fair use and detect denial-of-service attacks.
1057
1058
1059Section 6.1., paragraph 6:
1060OLD:
1061
1062    Connection options are case-insensitive.
1063
1064NEW:
1065
1066    Connection options are case insensitive.
1067
1068
1069Section 6.2., paragraph 1:
1070OLD:
1071
1072    It is beyond the scope of this specification to describe how
1073    connections are established via various transport or session-layer
1074    protocols.  Each connection applies to only one transport link.
1075
1076NEW:
1077
1078    It is beyond the scope of this specification to describe how
1079    connections are established via various transport- or session-layer
1080    protocols.  Each connection applies to only one transport link.
1081
1082
1083Section 6.3., paragraph 1:
1084OLD:
1085
1086    HTTP/1.1 defaults to the use of "persistent connections", allowing
1087    multiple requests and responses to be carried over a single
1088    connection.  The "close" connection-option is used to signal that a
1089    connection will not persist after the current request/response.  HTTP
1090    implementations SHOULD support persistent connections.
1091
1092NEW:
1093
1094    HTTP/1.1 defaults to the use of "persistent connections", allowing
1095    multiple requests and responses to be carried over a single
1096    connection.  The "close" connection option is used to signal that a
1097    connection will not persist after the current request/response.  HTTP
1098    implementations SHOULD support persistent connections.
1099
1100
1101Section 6.3., paragraph 3:
1102OLD:
1103
1104    o  If the close connection option is present, the connection will not
1105       persist after the current response; else,
1106
1107NEW:
1108
1109    o  If the "close" connection option is present, the connection will
1110       not persist after the current response; else,
1111
1112
1113Section 6.3., paragraph 7:
1114OLD:
1115
1116    A client MAY send additional requests on a persistent connection
1117    until it sends or receives a close connection option or receives an
1118    HTTP/1.0 response without a "keep-alive" connection option.
1119
1120NEW:
1121
1122    A client MAY send additional requests on a persistent connection
1123    until it sends or receives a "close" connection option or receives an
1124    HTTP/1.0 response without a "keep-alive" connection option.
1125
1126
1127Section 6.3., paragraph 10:
1128OLD:
1129
1130    See Appendix A.1.2 for more information on backward compatibility
1131    with HTTP/1.0 clients.
1132
1133NEW:
1134
1135    See Appendix A.1.2 for more information on backwards compatibility
1136    with HTTP/1.0 clients.
1137
1138
1139Section 6.3.2., paragraph 1:
1140OLD:
1141
1142    A client that supports persistent connections MAY "pipeline" its
1143    requests (i.e., send multiple requests without waiting for each
1144    response).  A server MAY process a sequence of pipelined requests in
1145    parallel if they all have safe methods (Section 4.2.1 of [RFC7231]),
1146    but MUST send the corresponding responses in the same order that the
1147    requests were received.
1148
1149NEW:
1150
1151    A client that supports persistent connections MAY "pipeline" its
1152    requests (i.e., send multiple requests without waiting for each
1153    response).  A server MAY process a sequence of pipelined requests in
1154    parallel if they all have safe methods (Section 4.2.1 of [RFC7231]),
1155    but it MUST send the corresponding responses in the same order that
1156    the requests were received.
1157
1158
1159Section 6.4., paragraph 4:
1160OLD:
1161
1162    Note that a server might reject traffic that it deems abusive or
1163    characteristic of a denial of service attack, such as an excessive
1164    number of open connections from a single client.
1165
1166NEW:
1167
1168    Note that a server might reject traffic that it deems abusive or
1169    characteristic of a denial-of-service attack, such as an excessive
1170    number of open connections from a single client.
1171
1172
1173Section 6.4., paragraph 5:
1174OLD:
1175
1176 6.5.  Failures and Time-outs
1177
1178NEW:
1179
1180 6.5.  Failures and Timeouts
1181
1182
1183Section 6.4., paragraph 6:
1184OLD:
1185
1186    Servers will usually have some time-out value beyond which they will
1187    no longer maintain an inactive connection.  Proxy servers might make
1188    this a higher value since it is likely that the client will be making
1189    more connections through the same proxy server.  The use of
1190    persistent connections places no requirements on the length (or
1191    existence) of this time-out for either the client or the server.
1192
1193NEW:
1194
1195    Servers will usually have some timeout value beyond which they will
1196    no longer maintain an inactive connection.  Proxy servers might make
1197    this a higher value since it is likely that the client will be making
1198    more connections through the same proxy server.  The use of
1199    persistent connections places no requirements on the length (or
1200    existence) of this timeout for either the client or the server.
1201
1202
1203Section 6.4., paragraph 7:
1204OLD:
1205
1206    A client or server that wishes to time-out SHOULD issue a graceful
1207    close on the connection.  Implementations SHOULD constantly monitor
1208    open connections for a received closure signal and respond to it as
1209    appropriate, since prompt closure of both sides of a connection
1210    enables allocated system resources to be reclaimed.
1211
1212NEW:
1213
1214    A client or server that wishes to time out SHOULD issue a graceful
1215    close on the connection.  Implementations SHOULD constantly monitor
1216    open connections for a received closure signal and respond to it as
1217    appropriate, since prompt closure of both sides of a connection
1218    enables allocated system resources to be reclaimed.
1219
1220
1221Section 6.4., paragraph 9:
1222OLD:
1223
1224    A server SHOULD sustain persistent connections, when possible, and
1225    allow the underlying transport's flow control mechanisms to resolve
1226    temporary overloads, rather than terminate connections with the
1227    expectation that clients will retry.  The latter technique can
1228    exacerbate network congestion.
1229
1230NEW:
1231
1232    A server SHOULD sustain persistent connections, when possible, and
1233    allow the underlying transport's flow-control mechanisms to resolve
1234    temporary overloads, rather than terminate connections with the
1235    expectation that clients will retry.  The latter technique can
1236    exacerbate network congestion.
1237
1238
1239Section 6.4., paragraph 11:
1240OLD:
1241
1242 6.6.  Tear-down
1243
1244NEW:
1245
1246 6.6.  Teardown
1247
1248
1249Section 6.4., paragraph 13:
1250OLD:
1251
1252    A client that sends a close connection option MUST NOT send further
1253    requests on that connection (after the one containing close) and MUST
1254    close the connection after reading the final response message
1255    corresponding to this request.
1256
1257NEW:
1258
1259    A client that sends a "close" connection option MUST NOT send further
1260    requests on that connection (after the one containing close) and MUST
1261    close the connection after reading the final response message
1262    corresponding to this request.
1263
1264
1265Section 6.4., paragraph 14:
1266OLD:
1267
1268    A server that receives a close connection option MUST initiate a
1269    close of the connection (see below) after it sends the final response
1270    to the request that contained close.  The server SHOULD send a close
1271    connection option in its final response on that connection.  The
1272    server MUST NOT process any further requests received on that
1273    connection.
1274
1275NEW:
1276
1277    A server that receives a "close" connection option MUST initiate a
1278    close of the connection (see below) after it sends the final response
1279    to the request that contained close.  The server SHOULD send a close
1280    connection option in its final response on that connection.  The
1281    server MUST NOT process any further requests received on that
1282    connection.
1283
1284
1285Section 6.4., paragraph 15:
1286OLD:
1287
1288    A server that sends a close connection option MUST initiate a close
1289    of the connection (see below) after it sends the response containing
1290    close.  The server MUST NOT process any further requests received on
1291    that connection.
1292
1293NEW:
1294
1295    A server that sends a "close" connection option MUST initiate a close
1296    of the connection (see below) after it sends the response containing
1297    close.  The server MUST NOT process any further requests received on
1298    that connection.
1299
1300
1301Section 6.4., paragraph 16:
1302OLD:
1303
1304    A client that receives a close connection option MUST cease sending
1305    requests on that connection and close the connection after reading
1306    the response message containing the close; if additional pipelined
1307    requests had been sent on the connection, the client SHOULD NOT
1308    assume that they will be processed by the server.
1309
1310NEW:
1311
1312    A client that receives a "close" connection option MUST cease sending
1313    requests on that connection and close the connection after reading
1314    the response message containing the close; if additional pipelined
1315    requests had been sent on the connection, the client SHOULD NOT
1316    assume that they will be processed by the server.
1317
1318
1319Section 6.4., paragraph 17:
1320OLD:
1321
1322    If a server performs an immediate close of a TCP connection, there is
1323    a significant risk that the client will not be able to read the last
1324    HTTP response.  If the server receives additional data from the
1325    client on a fully-closed connection, such as another request that was
1326    sent by the client before receiving the server's response, the
1327    server's TCP stack will send a reset packet to the client;
1328    unfortunately, the reset packet might erase the client's
1329    unacknowledged input buffers before they can be read and interpreted
1330    by the client's HTTP parser.
1331
1332NEW:
1333
1334    If a server performs an immediate close of a TCP connection, there is
1335    a significant risk that the client will not be able to read the last
1336    HTTP response.  If the server receives additional data from the
1337    client on a fully closed connection, such as another request that was
1338    sent by the client before receiving the server's response, the
1339    server's TCP stack will send a reset packet to the client;
1340    unfortunately, the reset packet might erase the client's
1341    unacknowledged input buffers before they can be read and interpreted
1342    by the client's HTTP parser.
1343
1344
1345Section 6.7., paragraph 9:
1346OLD:
1347
1348    The capabilities and nature of the application-level communication
1349    after the protocol change is entirely dependent upon the new
1350    protocol(s) chosen.  However, immediately after sending the 101
1351    response, the server is expected to continue responding to the
1352    original request as if it had received its equivalent within the new
1353    protocol (i.e., the server still has an outstanding request to
1354    satisfy after the protocol has been changed, and is expected to do so
1355    without requiring the request to be repeated).
1356
1357NEW:
1358
1359    The capabilities and nature of the application-level communication
1360    after the protocol change is entirely dependent upon the new
1361    protocol(s) chosen.  However, immediately after sending the 101
1362    (Switching Protocols) response, the server is expected to continue
1363    responding to the original request as if it had received its
1364    equivalent within the new protocol (i.e., the server still has an
1365    outstanding request to satisfy after the protocol has been changed,
1366    and is expected to do so without requiring the request to be
1367    repeated).
1368
1369
1370Section 101, paragraph 0:
1371OLD:
1372
1373    For example, if the Upgrade header field is received in a GET request
1374    and the server decides to switch protocols, it first responds with a
1375    101 (Switching Protocols) message in HTTP/1.1 and then immediately
1376    follows that with the new protocol's equivalent of a response to a
1377    GET on the target resource.  This allows a connection to be upgraded
1378    to protocols with the same semantics as HTTP without the latency cost
1379    of an additional round-trip.  A server MUST NOT switch protocols
1380    unless the received message semantics can be honored by the new
1381    protocol; an OPTIONS request can be honored by any protocol.
1382
1383NEW:
1384
1385    For example, if the Upgrade header field is received in a GET request
1386    and the server decides to switch protocols, it first responds with a
1387    101 (Switching Protocols) message in HTTP/1.1 and then immediately
1388    follows that with the new protocol's equivalent of a response to a
1389    GET on the target resource.  This allows a connection to be upgraded
1390    to protocols with the same semantics as HTTP without the latency cost
1391    of an additional round trip.  A server MUST NOT switch protocols
1392    unless the received message semantics can be honored by the new
1393    protocol; an OPTIONS request can be honored by any protocol.
1394
1395
1396Section 101, paragraph 5:
1397OLD:
1398
1399    A client cannot begin using an upgraded protocol on the connection
1400    until it has completely sent the request message (i.e., the client
1401    can't change the protocol it is sending in the middle of a message).
1402    If a server receives both Upgrade and an Expect header field with the
1403    "100-continue" expectation (Section 5.1.1 of [RFC7231]), the server
1404    MUST send a 100 (Continue) response before sending a 101 (Switching
1405    Protocols) response.
1406
1407NEW:
1408
1409    A client cannot begin using an upgraded protocol on the connection
1410    until it has completely sent the request message (i.e., the client
1411    can't change the protocol it is sending in the middle of a message).
1412    If a server receives both an Upgrade and an Expect header field with
1413    the "100-continue" expectation (Section 5.1.1 of [RFC7231]), the
1414    server MUST send a 100 (Continue) response before sending a 101
1415    (Switching Protocols) response.
1416
1417
1418Section 7., paragraph 9:
1419OLD:
1420
1421    For compatibility with legacy list rules, a recipient MUST parse and
1422    ignore a reasonable number of empty list elements: enough to handle
1423    common mistakes by senders that merge values, but not so much that
1424    they could be used as a denial of service mechanism.  In other words,
1425    a recipient MUST accept lists that satisfy the following syntax:
1426
1427NEW:
1428
1429    For compatibility with legacy list rules, a recipient MUST parse and
1430    ignore a reasonable number of empty list elements: enough to handle
1431    common mistakes by senders that merge values, but not so much that
1432    they could be used as a denial-of-service mechanism.  In other words,
1433    a recipient MUST accept lists that satisfy the following syntax:
1434
1435
1436Section 7., paragraph 14:
1437OLD:
1438
1439    Then the following are valid values for example-list (not including
1440    the double quotes, which are present for delimitation only):
1441
1442NEW:
1443
1444    Then, the following are valid values for example-list (not including
1445    the double quotes, which are present for delimitation only):
1446
1447
1448Section 8.1., paragraph 1:
1449OLD:
1450
1451    HTTP header fields are registered within the Message Header Field
1452    Registry maintained at
1453    <http://www.iana.org/assignments/message-headers/>.
1454
1455NEW:
1456
1457    HTTP header fields are registered within the "Message Header" field
1458    registry maintained at
1459    <http://www.iana.org/assignments/message-headers/>.
1460
1461
1462Section 8.1., paragraph 2:
1463OLD:
1464
1465    This document defines the following HTTP header fields, so their
1466    associated registry entries shall be updated according to the
1467    permanent registrations below (see [BCP90]):
1468
1469NEW:
1470
1471    This document defines the following HTTP header fields, so the
1472    "Permanent Message Header Field Names" registry has been updated
1473    accordingly (see [BCP90]).
1474
1475
1476Section 8.1., paragraph 4:
1477OLD:
1478
1479    Furthermore, the header field-name "Close" shall be registered as
1480    "reserved", since using that name as an HTTP header field might
1481    conflict with the "close" connection option of the "Connection"
1482    header field (Section 6.1).
1483
1484NEW:
1485
1486    Furthermore, the header field-name "Close" has been registered as
1487    "reserved", since using that name as an HTTP header field might
1488    conflict with the "close" connection option of the "Connection"
1489    header field (Section 6.1).
1490
1491
1492Section 8.2., paragraph 2:
1493OLD:
1494
1495    This document defines the following URI schemes, so their associated
1496    registry entries shall be updated according to the permanent
1497    registrations below:
1498
1499NEW:
1500
1501    This document defines the following URI schemes, so the "Permanent
1502    URI Schemes" registry has been updated accordingly.
1503
1504
1505Section 8.3., paragraph 2:
1506OLD:
1507
1508    This document serves as the specification for the Internet media
1509    types "message/http" and "application/http".  The following is to be
1510    registered with IANA.
1511
1512NEW:
1513
1514    This document serves as the specification for the Internet media
1515    types "message/http" and "application/http".  The following has been
1516    registered with IANA.
1517
1518
1519Section 8.3.1., paragraph 18:
1520OLD:
1521
1522    Person and email address to contact for further information:  See
1523       Authors' Addresses Section.
1524
1525NEW:
1526
1527    Person and email address to contact for further information:
1528       See Authors' Addresses  Section.
1529
1530
1531Section 8.3.2., paragraph 8:
1532OLD:
1533
1534    Encoding considerations:  HTTP messages enclosed by this type are in
1535       "binary" format; use of an appropriate Content-Transfer-Encoding
1536       is required when transmitted via E-mail.
1537
1538NEW:
1539
1540    Encoding considerations:  HTTP messages enclosed by this type are in
1541       "binary" format; use of an appropriate Content-Transfer-Encoding
1542       is required when transmitted via email.
1543
1544
1545Section 8.3.2., paragraph 19:
1546OLD:
1547
1548    Person and email address to contact for further information:  See
1549       Authors' Addresses Section.
1550
1551NEW:
1552
1553    Person and email address to contact for further information:
1554       See Authors' Addresses Section.
1555
1556
1557Section 8.4., paragraph 1:
1558OLD:
1559
1560    The HTTP Transfer Coding Registry defines the name space for transfer
1561    coding names.  It is maintained at
1562    <http://www.iana.org/assignments/http-parameters>.
1563
1564NEW:
1565
1566    The "HTTP Transfer Coding" registry defines the namespace for
1567    transfer coding names.  It is maintained at
1568    <http://www.iana.org/assignments/http-parameters>.
1569
1570
1571Section 8.4.1., paragraph 5:
1572OLD:
1573
1574    Values to be added to this name space require IETF Review (see
1575    Section 4.1 of [RFC5226]), and MUST conform to the purpose of
1576    transfer coding defined in this specification.
1577
1578NEW:
1579
1580    Values to be added to this namespace require IETF Review (see Section
1581    4.1 of [RFC5226]), and MUST conform to the purpose of transfer coding
1582    defined in this specification.
1583
1584
1585Section 8.4.2., paragraph 1:
1586OLD:
1587
1588    The HTTP Transfer Coding Registry shall be updated with the
1589    registrations below:
1590
1591NEW:
1592
1593    The "HTTP Transfer Coding Registry" has been updated with the
1594    registrations below:
1595
1596
1597Section 8.5., paragraph 1:
1598OLD:
1599
1600    IANA maintains the registry of HTTP Content Codings at
1601    <http://www.iana.org/assignments/http-parameters>.
1602
1603NEW:
1604
1605    IANA maintains the "HTTP Content Coding Registry" at
1606    <http://www.iana.org/assignments/http-parameters>.
1607
1608
1609Section 8.5., paragraph 2:
1610OLD:
1611
1612    The HTTP Content Codings Registry shall be updated with the
1613    registrations below:
1614
1615NEW:
1616
1617    The "HTTP Content Codings Registry" has been updated with the
1618    registrations below:
1619
1620
1621Section 8.6., paragraph 1:
1622OLD:
1623
1624    The HTTP Upgrade Token Registry defines the name space for protocol-
1625    name tokens used to identify protocols in the Upgrade header field.
1626    The registry is maintained at
1627    <http://www.iana.org/assignments/http-upgrade-tokens>.
1628
1629NEW:
1630
1631    The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
1632    defines the namespace for protocol-name tokens used to identify
1633    protocols in the Upgrade header field.  The registry is maintained at
1634    <http://www.iana.org/assignments/http-upgrade-tokens>.
1635
1636
1637Section 8.6.2., paragraph 1:
1638OLD:
1639
1640    The "HTTP" entry in the HTTP Upgrade Token Registry shall be updated
1641    with the registration below:
1642
1643NEW:
1644
1645    The "HTTP" entry in the "HTTP Upgrade Token" registry shall be
1646    updated with the registration below:
1647
1648
1649Section 9.1., paragraph 3:
1650OLD:
1651
1652    When a registered name is used in the authority component, the "http"
1653    URI scheme (Section 2.7.1) relies on the user's local name resolution
1654    service to determine where it can find authoritative responses.  This
1655    means that any attack on a user's network host table, cached names,
1656    or name resolution libraries becomes an avenue for attack on
1657    establishing authority.  Likewise, the user's choice of server for
1658    Domain Name Service (DNS), and the hierarchy of servers from which it
1659    obtains resolution results, could impact the authenticity of address
1660    mappings; DNSSEC ([RFC4033]) is one way to improve authenticity.
1661
1662NEW:
1663
1664    When a registered name is used in the authority component, the "http"
1665    URI scheme (Section 2.7.1) relies on the user's local name resolution
1666    service to determine where it can find authoritative responses.  This
1667    means that any attack on a user's network host table, cached names,
1668    or name resolution libraries becomes an avenue for attack on
1669    establishing authority.  Likewise, the user's choice of server for
1670    Domain Name Service (DNS), and the hierarchy of servers from which it
1671    obtains resolution results, could impact the authenticity of address
1672    mappings; DNS Security Extensions (DNSSEC) ([RFC4033]) is one way to
1673    improve authenticity.
1674
1675
1676Section 9.2., paragraph 1:
1677OLD:
1678
1679    By their very nature, HTTP intermediaries are men-in-the-middle, and
1680    thus represent an opportunity for man-in-the-middle attacks.
1681    Compromise of the systems on which the intermediaries run can result
1682    in serious security and privacy problems.  Intermediaries might have
1683    access to security-related information, personal information about
1684    individual users and organizations, and proprietary information
1685    belonging to users and content providers.  A compromised
1686    intermediary, or an intermediary implemented or configured without
1687    regard to security and privacy considerations, might be used in the
1688    commission of a wide range of potential attacks.
1689
1690NEW:
1691
1692    By their very nature, HTTP intermediaries are men in the middle and,
1693    thus, represent an opportunity for man-in-the-middle attacks.
1694    Compromise of the systems on which the intermediaries run can result
1695    in serious security and privacy problems.  Intermediaries might have
1696    access to security-related information, personal information about
1697    individual users and organizations, and proprietary information
1698    belonging to users and content providers.  A compromised
1699    intermediary, or an intermediary implemented or configured without
1700    regard to security and privacy considerations, might be used in the
1701    commission of a wide range of potential attacks.
1702
1703
1704Section 9.3., paragraph 4:
1705OLD:
1706
1707    Recipients ought to carefully limit the extent to which they process
1708    other protocol elements, including (but not limited to) request
1709    methods, response status phrases, header field-names, numeric values,
1710    and body chunks.  Failure to limit such processing can result in
1711    buffer overflows, arithmetic overflows, or increased vulnerability to
1712    denial of service attacks.
1713
1714NEW:
1715
1716    Recipients ought to carefully limit the extent to which they process
1717    other protocol elements, including (but not limited to) request
1718    methods, response status phrases, header field-names, numeric values,
1719    and body chunks.  Failure to limit such processing can result in
1720    buffer overflows, arithmetic overflows, or increased vulnerability to
1721    denial-of-service attacks.
1722
1723
1724Section 9.6., paragraph 2:
1725OLD:
1726
1727    User agents are encouraged to implement configurable means for
1728    detecting and reporting failures of message integrity such that those
1729    means can be enabled within environments for which integrity is
1730    necessary.  For example, a browser being used to view medical history
1731    or drug interaction information needs to indicate to the user when
1732    such information is detected by the protocol to be incomplete,
1733    expired, or corrupted during transfer.  Such mechanisms might be
1734    selectively enabled via user agent extensions or the presence of
1735    message integrity metadata in a response.  At a minimum, user agents
1736    ought to provide some indication that allows a user to distinguish
1737    between a complete and incomplete response message (Section 3.4) when
1738    such verification is desired.
1739
1740NEW:
1741
1742    User agents are encouraged to implement configurable means for
1743    detecting and reporting failures of message integrity such that those
1744    means can be enabled within environments for which integrity is
1745    necessary.  For example, a browser being used to view medical history
1746    or drug interaction information needs to indicate to the user when
1747    such information is detected by the protocol to be incomplete,
1748    expired, or corrupted during transfer.  Such mechanisms might be
1749    selectively enabled via user-agent extensions or the presence of
1750    message integrity metadata in a response.  At a minimum, user agents
1751    ought to provide some indication that allows a user to distinguish
1752    between a complete and incomplete response message (Section 3.4) when
1753    such verification is desired.
1754
1755
1756Section 9.8., paragraph 2:
1757OLD:
1758
1759    HTTP log information is confidential in nature; its handling is often
1760    constrained by laws and regulations.  Log information needs to be
1761    securely stored and appropriate guidelines followed for its analysis.
1762    Anonymization of personal information within individual entries
1763    helps, but is generally not sufficient to prevent real log traces
1764    from being re-identified based on correlation with other access
1765    characteristics.  As such, access traces that are keyed to a specific
1766    client are unsafe to publish even if the key is pseudonymous.
1767
1768NEW:
1769
1770    HTTP log information is confidential in nature; its handling is often
1771    constrained by laws and regulations.  Log information needs to be
1772    securely stored and appropriate guidelines followed for its analysis.
1773    Anonymization of personal information within individual entries
1774    helps, but it is generally not sufficient to prevent real log traces
1775    from being re-identified based on correlation with other access
1776    characteristics.  As such, access traces that are keyed to a specific
1777    client are unsafe to publish even if the key is pseudonymous.
1778
1779
1780Section 11.1., paragraph 1:
1781OLD:
1782
1783    [RFC0793]     Postel, J., "Transmission Control Protocol", STD 7,
1784                  RFC 793, September 1981.
1785 
1786    [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
1787                  Format Specification version 3.3", RFC 1950, May 1996.
1788
1789NEW:
1790
1791    [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
1792                  Format Specification version 3.3", RFC 1950, May 1996.
1793
1794
1795Section 11.1., paragraph 7:
1796OLD:
1797
1798    [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1799                  Transfer Protocol (HTTP/1.1): Semantics and Content",
1800                  draft-ietf-httpbis-p2-semantics-latest (work in
1801                  progress), May 2014.
1802
1803NEW:
1804
1805    [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1806                  Transfer Protocol (HTTP/1.1): Semantics and Content",
1807                  RFC 7231, May 2014.
1808
1809
1810Section 11.1., paragraph 8:
1811OLD:
1812
1813    [RFC7232]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1814                  Transfer Protocol (HTTP/1.1): Conditional Requests",
1815                  draft-ietf-httpbis-p4-conditional-latest (work in
1816                  progress), May 2014.
1817
1818NEW:
1819
1820    [RFC7232]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1821                  Transfer Protocol (HTTP/1.1): Conditional Requests",
1822                  RFC 7232, May 2014.
1823
1824
1825Section 11.1., paragraph 9:
1826OLD:
1827
1828    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1829                  "Hypertext Transfer Protocol (HTTP/1.1): Range
1830                  Requests", draft-ietf-httpbis-p5-range-latest (work in
1831                  progress), May 2014.
1832
1833NEW:
1834
1835    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1836                  "Hypertext Transfer Protocol (HTTP/1.1): Range
1837                  Requests", RFC 7233, May 2014.
1838
1839
1840Section 11.1., paragraph 10:
1841OLD:
1842
1843    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1844                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1845                  draft-ietf-httpbis-p6-cache-latest (work in progress),
1846                  May 2014.
1847
1848NEW:
1849
1850    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1851                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1852                  RFC 7234, May 2014.
1853
1854
1855Section 11.1., paragraph 11:
1856OLD:
1857
1858    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1859                  Transfer Protocol (HTTP/1.1): Authentication",
1860                  draft-ietf-httpbis-p7-auth-latest (work in progress),
1861                  May 2014.
1862
1863NEW:
1864
1865    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1866                  Transfer Protocol (HTTP/1.1): Authentication",
1867                  RFC 7235, May 2014.
1868 
1869    [RFC793]      Postel, J., "Transmission Control Protocol", STD 7,
1870                  RFC 793, September 1981.
1871
1872
1873Section 11.1., paragraph 13:
1874OLD:
1875
1876    [Welch]       Welch, T., "A Technique for High Performance Data
1877                  Compression", IEEE Computer 17(6), June 1984.
1878
1879NEW:
1880
1881    [Welch]       Welch, T., "A Technique for High-Performance Data
1882                  Compression", IEEE Computer 17(6), June 1984.
1883
1884
1885Appendix A., paragraph 1:
1886OLD:
1887
1888    HTTP has been in use since 1990.  The first version, later referred
1889    to as HTTP/0.9, was a simple protocol for hypertext data transfer
1890    across the Internet, using only a single request method (GET) and no
1891    metadata.  HTTP/1.0, as defined by [RFC1945], added a range of
1892    request methods and MIME-like messaging, allowing for metadata to be
1893    transferred and modifiers placed on the request/response semantics.
1894    However, HTTP/1.0 did not sufficiently take into consideration the
1895    effects of hierarchical proxies, caching, the need for persistent
1896    connections, or name-based virtual hosts.  The proliferation of
1897    incompletely-implemented applications calling themselves "HTTP/1.0"
1898    further necessitated a protocol version change in order for two
1899    communicating applications to determine each other's true
1900    capabilities.
1901
1902NEW:
1903
1904    HTTP has been in use since 1990.  The first version, later referred
1905    to as HTTP/0.9, was a simple protocol for hypertext data transfer
1906    across the Internet, using only a single request method (GET) and no
1907    metadata.  HTTP/1.0, as defined by [RFC1945], added a range of
1908    request methods and MIME-like messaging, allowing for metadata to be
1909    transferred and modifiers placed on the request/response semantics.
1910    However, HTTP/1.0 did not sufficiently take into consideration the
1911    effects of hierarchical proxies, caching, the need for persistent
1912    connections, or name-based virtual hosts.  The proliferation of
1913    incompletely implemented applications calling themselves "HTTP/1.0"
1914    further necessitated a protocol version change in order for two
1915    communicating applications to determine each other's true
1916    capabilities.
1917
1918
1919Appendix A., paragraph 2:
1920OLD:
1921
1922    HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
1923    requirements that enable reliable implementations, adding only those
1924    features that can either be safely ignored by an HTTP/1.0 recipient
1925    or only sent when communicating with a party advertising conformance
1926    with HTTP/1.1.
1927
1928NEW:
1929
1930    HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
1931    requirements that enable reliable implementations, adding only those
1932    features that can either be safely ignored by an HTTP/1.0 recipient
1933    or only be sent when communicating with a party advertising
1934    conformance with HTTP/1.1.
1935
1936
1937Appendix A., paragraph 7:
1938OLD:
1939
1940 A.1.1.  Multi-homed Web Servers
1941
1942NEW:
1943
1944 A.1.1.  Multihomed Web Servers
1945
1946
1947Section 19.7.1, paragraph 8:
1948OLD:
1949
1950    HTTP's approach to error handling has been explained.  (Section 2.5)
1951
1952NEW:
1953
1954    HTTP's approach to error handling has been explained (Section 2.5).
1955
1956
1957Section 19.7.1, paragraph 9:
1958OLD:
1959
1960    The HTTP-version ABNF production has been clarified to be case-
1961    sensitive.  Additionally, version numbers has been restricted to
1962    single digits, due to the fact that implementations are known to
1963    handle multi-digit version numbers incorrectly.  (Section 2.6)
1964
1965NEW:
1966
1967    The HTTP-version ABNF production has been clarified to be case
1968    sensitive.  Additionally, version numbers have been restricted to
1969    single digits, due to the fact that implementations are known to
1970    handle multi-digit version numbers incorrectly (Section 2.6).
1971
1972
1973Section 19.7.1, paragraph 10:
1974OLD:
1975
1976    Userinfo (i.e., username and password) are now disallowed in HTTP and
1977    HTTPS URIs, because of security issues related to their transmission
1978    on the wire.  (Section 2.7.1)
1979
1980NEW:
1981
1982    Userinfo (i.e., username and password) are now disallowed in HTTP and
1983    HTTPS URIs, because of security issues related to their transmission
1984    on the wire (Section 2.7.1).
1985
1986
1987Section 19.7.1, paragraph 11:
1988OLD:
1989
1990    The HTTPS URI scheme is now defined by this specification;
1991    previously, it was done in Section 2.4 of [RFC2818].  Furthermore, it
1992    implies end-to-end security.  (Section 2.7.2)
1993
1994NEW:
1995
1996    The HTTPS URI scheme is now defined by this specification;
1997    previously, it was defined in Section 2.4 of [RFC2818].  Furthermore,
1998    it implies end-to-end security (Section 2.7.2).
1999
2000
2001Section 19.7.1, paragraph 12:
2002OLD:
2003
2004    HTTP messages can be (and often are) buffered by implementations;
2005    despite it sometimes being available as a stream, HTTP is
2006    fundamentally a message-oriented protocol.  Minimum supported sizes
2007    for various protocol elements have been suggested, to improve
2008    interoperability.  (Section 3)
2009
2010NEW:
2011
2012    HTTP messages can be (and often are) buffered by implementations;
2013    despite it sometimes being available as a stream, HTTP is
2014    fundamentally a message-oriented protocol.  Minimum supported sizes
2015    for various protocol elements have been suggested, to improve
2016    interoperability (Section 3).
2017
2018
2019Section 19.7.1, paragraph 13:
2020OLD:
2021
2022    Invalid whitespace around field-names is now required to be rejected,
2023    because accepting it represents a security vulnerability.  The ABNF
2024    productions defining header fields now only list the field value.
2025    (Section 3.2)
2026
2027NEW:
2028
2029    Invalid whitespace around field-names is now required to be rejected,
2030    because accepting it represents a security vulnerability.  The ABNF
2031    productions defining header fields now only list the field value
2032    (Section 3.2).
2033
2034
2035Section 19.7.1, paragraph 14:
2036OLD:
2037
2038    Rules about implicit linear whitespace between certain grammar
2039    productions have been removed; now whitespace is only allowed where
2040    specifically defined in the ABNF.  (Section 3.2.3)
2041
2042NEW:
2043
2044    Rules about implicit linear whitespace between certain grammar
2045    productions have been removed; now whitespace is only allowed where
2046    specifically defined in the ABNF (Section 3.2.3).
2047
2048
2049Section 19.7.1, paragraph 15:
2050OLD:
2051
2052    Header fields that span multiple lines ("line folding") are
2053    deprecated.  (Section 3.2.4)
2054    The NUL octet is no longer allowed in comment and quoted-string text,
2055    and handling of backslash-escaping in them has been clarified.  The
2056    quoted-pair rule no longer allows escaping control characters other
2057    than HTAB.  Non-ASCII content in header fields and the reason phrase
2058    has been obsoleted and made opaque (the TEXT rule was removed).
2059    (Section 3.2.6)
2060
2061NEW:
2062
2063    Header fields that span multiple lines ("line folding") are
2064    deprecated (Section 3.2.4).
2065 
2066    The NUL octet is no longer allowed in comment and quoted-string text,
2067    and handling of backslash-escaping in them has been clarified.  The
2068    quoted-pair rule no longer allows escaping control characters other
2069    than HTAB.  Non-US-ASCII content in header fields and the reason
2070    phrase has been obsoleted and made opaque (the TEXT rule was removed)
2071    (Section 3.2.6).
2072
2073
2074Section 19.7.1, paragraph 16:
2075OLD:
2076
2077    Bogus "Content-Length" header fields are now required to be handled
2078    as errors by recipients.  (Section 3.3.2)
2079
2080NEW:
2081
2082    Bogus "Content-Length" header fields are now required to be handled
2083    as errors by recipients (Section 3.3.2).
2084
2085
2086Section 19.7.1, paragraph 17:
2087OLD:
2088
2089    The algorithm for determining the message body length has been
2090    clarified to indicate all of the special cases (e.g., driven by
2091    methods or status codes) that affect it, and that new protocol
2092    elements cannot define such special cases.  CONNECT is a new, special
2093    case in determining message body length. "multipart/byteranges" is no
2094    longer a way of determining message body length detection.
2095    (Section 3.3.3)
2096
2097NEW:
2098
2099    The algorithm for determining the message body length has been
2100    clarified to indicate all of the special cases (e.g., driven by
2101    methods or status codes) that affect it, and that new protocol
2102    elements cannot define such special cases.  CONNECT is a new, special
2103    case in determining message body length. "multipart/byteranges" is no
2104    longer a way of determining message body length detection
2105    (Section 3.3.3).
2106
2107
2108Section 19.7.1, paragraph 18:
2109OLD:
2110
2111    The "identity" transfer coding token has been removed.  (Sections 3.3
2112    and 4)
2113
2114NEW:
2115
2116    The "identity" transfer coding token has been removed (Sections 3.3
2117    and 4).
2118
2119
2120Section 19.7.1, paragraph 19:
2121OLD:
2122
2123    Chunk length does not include the count of the octets in the chunk
2124    header and trailer.  Line folding in chunk extensions is disallowed.
2125    (Section 4.1)
2126
2127NEW:
2128
2129    Chunk length does not include the count of the octets in the chunk
2130    header and trailer.  Line folding in chunk extensions is disallowed
2131    (Section 4.1).
2132
2133
2134Section 19.7.1, paragraph 20:
2135OLD:
2136
2137    The meaning of the "deflate" content coding has been clarified.
2138    (Section 4.2.2)
2139
2140NEW:
2141
2142    The meaning of the "deflate" content coding has been clarified
2143    (Section 4.2.2).
2144
2145
2146Section 19.7.1, paragraph 21:
2147OLD:
2148
2149    The segment + query components of RFC 3986 have been used to define
2150    the request-target, instead of abs_path from RFC 1808.  The asterisk-
2151    form of the request-target is only allowed with the OPTIONS method.
2152    (Section 5.3)
2153
2154NEW:
2155
2156    The segment + query components of RFC 3986 have been used to define
2157    the request-target, instead of abs_path from RFC 1808.  The asterisk-
2158    form of the request-target is only allowed with the OPTIONS method
2159    (Section 5.3).
2160
2161
2162Section 19.7.1, paragraph 22:
2163OLD:
2164
2165    The term "Effective Request URI" has been introduced.  (Section 5.5)
2166
2167NEW:
2168
2169    The term "Effective Request URI" has been introduced (Section 5.5).
2170
2171
2172Section 19.7.1, paragraph 23:
2173OLD:
2174
2175    Gateways do not need to generate Via header fields anymore.
2176    (Section 5.7.1)
2177
2178NEW:
2179
2180    Gateways do not need to generate Via header fields anymore
2181    (Section 5.7.1).
2182
2183
2184Section 19.7.1, paragraph 24:
2185OLD:
2186
2187    Exactly when "close" connection options have to be sent has been
2188    clarified.  Also, "hop-by-hop" header fields are required to appear
2189    in the Connection header field; just because they're defined as hop-
2190    by-hop in this specification doesn't exempt them.  (Section 6.1)
2191
2192NEW:
2193
2194    Exactly when "close" connection options have to be sent has been
2195    clarified.  Also, "hop-by-hop" header fields are required to appear
2196    in the Connection header field; just because they're defined as hop-
2197    by-hop in this specification doesn't exempt them (Section 6.1).
2198
2199
2200Section 19.7.1, paragraph 25:
2201OLD:
2202
2203    The limit of two connections per server has been removed.  An
2204    idempotent sequence of requests is no longer required to be retried.
2205    The requirement to retry requests under certain circumstances when
2206    the server prematurely closes the connection has been removed.  Also,
2207    some extraneous requirements about when servers are allowed to close
2208    connections prematurely have been removed.  (Section 6.3)
2209
2210NEW:
2211
2212    The limit of two connections per server has been removed.  An
2213    idempotent sequence of requests is no longer required to be retried.
2214    The requirement to retry requests under certain circumstances when
2215    the server prematurely closes the connection has been removed.  Also,
2216    some extraneous requirements about when servers are allowed to close
2217    connections prematurely have been removed (Section 6.3).
2218
2219
2220Section 19.7.1, paragraph 26:
2221OLD:
2222
2223    The semantics of the Upgrade header field is now defined in responses
2224    other than 101 (this was incorporated from [RFC2817]).  Furthermore,
2225    the ordering in the field value is now significant.  (Section 6.7)
2226
2227NEW:
2228
2229    The semantics of the Upgrade header field is now defined in responses
2230    other than 101 (this was incorporated from [RFC2817]).  Furthermore,
2231    the ordering in the field value is now significant (Section 6.7).
2232
2233
2234Section 19.7.1, paragraph 27:
2235OLD:
2236
2237    Empty list elements in list productions (e.g., a list header field
2238    containing ", ,") have been deprecated.  (Section 7)
2239
2240NEW:
2241
2242    Empty list elements in list productions (e.g., a list header field
2243    containing ", ,") have been deprecated (Section 7).
2244
2245
2246Section 19.7.1, paragraph 28:
2247OLD:
2248
2249    Registration of Transfer Codings now requires IETF Review
2250    (Section 8.4)
2251
2252NEW:
2253
2254    Registration of Transfer Codings now requires IETF Review
2255    (Section 8.4).
2256
2257
2258Section 19.7.1, paragraph 29:
2259OLD:
2260
2261    This specification now defines the Upgrade Token Registry, previously
2262    defined in Section 7.2 of [RFC2817].  (Section 8.6)
2263
2264NEW:
2265
2266    This specification now defines the "HTTP Upgrade Tokens" registry,
2267    previously defined in Section 7.2 of [RFC2817] (Section 8.6).
2268
2269
2270Section 19.7.1, paragraph 30:
2271OLD:
2272
2273    The expectation to support HTTP/0.9 requests has been removed.
2274    (Appendix A)
2275
2276NEW:
2277
2278    The expectation to support HTTP/0.9 requests has been removed
2279    (Appendix A).
2280
2281
2282Section 19.7.1, paragraph 31:
2283OLD:
2284
2285    Issues with the Keep-Alive and Proxy-Connection header fields in
2286    requests are pointed out, with use of the latter being discouraged
2287    altogether.  (Appendix A.1.2)
2288
2289NEW:
2290
2291    Issues with the Keep-Alive and Proxy-Connection header fields in
2292    requests are pointed out, with use of the latter being discouraged
2293    altogether (Appendix A.1.2).
2294
2295
2296Appendix B., paragraph 7:
2297OLD:
2298
2299    URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
2300    Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
2301    Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
2302     ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
2303     comment ] ) ] )
2304
2305NEW:
2306
2307    URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
2308    Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
2309 
2310    Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
2311     ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
2312     comment ] ) ] )
2313
2314
2315Appendix B., paragraph 15:
2316OLD:
2317
2318    partial-URI = relative-part [ "?" query ]
2319    path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
2320    port = <port, defined in [RFC3986], Section 3.2.3>
2321    protocol = protocol-name [ "/" protocol-version ]
2322    protocol-name = token
2323    protocol-version = token
2324    pseudonym = token
2325 
2326    qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
2327     / %x5D-7E ; ']'-'~'
2328     / obs-text
2329    query = <query, defined in [RFC3986], Section 3.4>
2330    quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
2331    quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
2332
2333NEW:
2334
2335    partial-URI = relative-part [ "?" query ]
2336    path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
2337    port = <port, defined in [RFC3986], Section 3.2.3>
2338    protocol = protocol-name [ "/" protocol-version ]
2339    protocol-name = token
2340    protocol-version = token
2341    pseudonym = token
2342    qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
2343     / %x5D-7E ; ']'-'~'
2344     / obs-text
2345    query = <query, defined in [RFC3986], Section 3.4>
2346    quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
2347    quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
2348
2349
2350Appendix B., paragraph 24:
2351OLD:
2352
2353    D
2354       deflate (Coding Format)  38
2355       Delimiters  26
2356       downstream  9
2357
2358NEW:
2359
2360    D
2361       deflate (Coding Format)  38
2362       Delimiters  26
2363       downstream  10
2364
2365
2366Appendix B., paragraph 26:
2367OLD:
2368
2369    G
2370       gateway  10
2371       Grammar
2372          absolute-form  41-42
2373          absolute-path  16
2374          absolute-URI  16
2375          ALPHA  6
2376          asterisk-form  41-42
2377          authority  16
2378          authority-form  41-42
2379          BWS  24
2380          chunk  35
2381          chunk-data  35
2382          chunk-ext  35-36
2383          chunk-ext-name  36
2384          chunk-ext-val  36
2385          chunk-size  35
2386          chunked-body  35-36
2387          comment  27
2388          Connection  51
2389          connection-option  51
2390          Content-Length  30
2391          CR  6
2392          CRLF  6
2393          ctext  27
2394          CTL  6
2395          DIGIT  6
2396          DQUOTE  6
2397          field-content  22
2398          field-name  22, 39
2399          field-value  22
2400          field-vchar  22
2401          fragment  16
2402          header-field  22, 36
2403          HEXDIG  6
2404          Host  43
2405          HTAB  6
2406          HTTP-message  19
2407          HTTP-name  13
2408          http-URI  16
2409          HTTP-version  13
2410          https-URI  18
2411          last-chunk  35
2412          LF  6
2413          message-body  27
2414          method  21
2415          obs-fold  22
2416          obs-text  27
2417          OCTET  6
2418          origin-form  41
2419          OWS  24
2420          partial-URI  16
2421          port  16
2422          protocol-name  47
2423          protocol-version  47
2424          pseudonym  47
2425          qdtext  27
2426          query  16
2427          quoted-pair  27
2428          quoted-string  27
2429          rank  38
2430          reason-phrase  22
2431          received-by  47
2432          received-protocol  47
2433          request-line  21
2434          request-target  41
2435          RWS  24
2436          scheme  16
2437          segment  16
2438          SP  6
2439          start-line  20
2440          status-code  22
2441          status-line  22
2442          t-codings  38
2443          t-ranking  38
2444          tchar  27
2445          TE  38
2446          token  27
2447          Trailer  39
2448          trailer-part  35-36
2449          transfer-coding  35
2450          Transfer-Encoding  28
2451          transfer-extension  35
2452          transfer-parameter  35
2453          Upgrade  56
2454          uri-host  16
2455          URI-reference  16
2456          VCHAR  6
2457          Via  47
2458       gzip (Coding Format)  38
2459
2460NEW:
2461
2462    G
2463       gateway  10
2464       Grammar
2465          absolute-form  41-42
2466          absolute-path  16
2467          absolute-URI  16
2468          ALPHA  6
2469          asterisk-form  41-42
2470          authority  16
2471          authority-form  41-42
2472          BWS  24
2473          chunk  35
2474          chunk-data  35
2475          chunk-ext  35-36
2476          chunk-ext-name  36
2477          chunk-ext-val  36
2478          chunk-size  35
2479          chunked-body  35-36
2480          comment  27
2481          Connection  51
2482          connection-option  51
2483          Content-Length  30
2484          CR  6
2485          CRLF  6
2486          ctext  27
2487          CTL  6
2488          DIGIT  6
2489          DQUOTE  6
2490          field-content  22
2491          field-name  22, 39
2492          field-value  22
2493          field-vchar  22
2494          fragment  16
2495          header-field  22, 36
2496          HEXDIG  6
2497          Host  43
2498          HTAB  6
2499          HTTP-message  19
2500          HTTP-name  14
2501          http-URI  16
2502          HTTP-version  14
2503          https-URI  18
2504          last-chunk  35
2505          LF  6
2506          message-body  27
2507          method  21
2508          obs-fold  22
2509          obs-text  27
2510          OCTET  6
2511          origin-form  41
2512          OWS  24
2513          partial-URI  16
2514          port  16
2515          protocol-name  47
2516          protocol-version  47
2517          pseudonym  47
2518          qdtext  27
2519          query  16
2520          quoted-pair  27
2521          quoted-string  27
2522          rank  38
2523          reason-phrase  22
2524          received-by  47
2525          received-protocol  47
2526          request-line  21
2527          request-target  41
2528          RWS  24
2529          scheme  16
2530          segment  16
2531          SP  6
2532          start-line  20
2533          status-code  22
2534          status-line  22
2535          t-codings  38
2536          t-ranking  38
2537          tchar  27
2538          TE  38
2539          token  27
2540          Trailer  39
2541          trailer-part  35-36
2542          transfer-coding  35
2543          Transfer-Encoding  28
2544          transfer-extension  35
2545          transfer-parameter  35
2546          Upgrade  56
2547          uri-host  16
2548          URI-reference  16
2549          VCHAR  6
2550          Via  47
2551       gzip (Coding Format)  38
2552
2553
2554Appendix B., paragraph 28:
2555OLD:
2556
2557    I
2558       inbound  9
2559       interception proxy  11
2560       intermediary  9
2561
2562NEW:
2563
2564    I
2565       inbound  10
2566       interception proxy  11
2567       intermediary  9
2568
2569
2570Appendix B., paragraph 31:
2571OLD:
2572
2573    O
2574       origin server  7
2575       origin-form (of request-target)  41
2576       outbound  9
2577
2578NEW:
2579
2580    O
2581       origin server  7
2582       origin-form (of request-target)  41
2583       outbound  10
2584
2585
2586Appendix B., paragraph 36:
2587OLD:
2588
2589    U
2590       Upgrade header field  56
2591       upstream  9
2592       URI scheme
2593          http  16
2594          https  18
2595       user agent  7
2596
2597NEW:
2598
2599    U
2600       Upgrade header field  56
2601       upstream  10
2602       URI scheme
2603          http  16
2604          https  18
2605       user agent  7
2606
2607
2608Section 345, paragraph 1:
2609OLD:
2610
2611    EMail: fielding@gbiv.com
2612    URI:   http://roy.gbiv.com/
2613 
2614    Julian F. Reschke (editor)
2615    greenbytes GmbH
2616    Hafenweg 16
2617    Muenster, NW  48155
2618    Germany
2619
2620NEW:
2621
2622    EMail: fielding@gbiv.com
2623    URI:   http://roy.gbiv.com/
2624    Julian F. Reschke (editor)
2625    greenbytes GmbH
2626    Hafenweg 16
2627    Muenster, NW  48155
2628    Germany
2629
Note: See TracBrowser for help on using the repository browser.