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

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

IANA considerations: vertical ws, past tense (#553)

File size: 70.9 KB
Line 
1
2INTRODUCTION, paragraph 1:
3OLD:
4
5 HTTPbis Working Group                                   R. Fielding, Ed.
6 Internet-Draft                                                     Adobe
7 Obsoletes: 2145, 2616                                    J. Reschke, Ed.
8 (if approved)                                                 greenbytes
9 Updates: 2817, 2818 (if approved)                            May 7, 2014
10 Intended status: Standards Track
11 Expires: November 8, 2014
12
13NEW:
14
15 Internet Engineering Task Force (IETF)                  R. Fielding, Ed.
16 Request for Comments: 7230                                         Adobe
17 Obsoletes: 2145, 2616                                    J. Reschke, Ed.
18 Updates: 2817, 2818                                           greenbytes
19 Category: Standards Track                                       May 2014
20 ISSN: 2070-1721
21
22
23INTRODUCTION, paragraph 2:
24OLD:
25
26    Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
27                  draft-ietf-httpbis-p1-messaging-latest
28
29NEW:
30
31    Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
32
33
34INTRODUCTION, paragraph 5:
35OLD:
36
37 Editorial Note (To be removed by RFC Editor)
38 
39    Discussion of this draft takes place on the HTTPBIS working group
40    mailing list (ietf-http-wg@w3.org), which is archived at
41    <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
42 
43    The current issues list is at
44    <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
45    documents (including fancy diffs) can be found at
46    <http://tools.ietf.org/wg/httpbis/>.
47 
48    _This is a temporary document for the purpose of tracking the
49    editorial changes made during the AUTH48 (RFC publication) phase._
50 
51 Status of This Memo
52
53NEW:
54
55 Status of This Memo
56
57
58INTRODUCTION, paragraph 6:
59OLD:
60
61    This Internet-Draft is submitted in full conformance with the
62    provisions of BCP 78 and BCP 79.
63 
64    Internet-Drafts are working documents of the Internet Engineering
65    Task Force (IETF).  Note that other groups may also distribute
66    working documents as Internet-Drafts.  The list of current Internet-
67    Drafts is at http://datatracker.ietf.org/drafts/current/.
68
69NEW:
70
71    This is an Internet Standards Track document.
72
73
74INTRODUCTION, paragraph 7:
75OLD:
76
77    Internet-Drafts are draft documents valid for a maximum of six months
78    and may be updated, replaced, or obsoleted by other documents at any
79    time.  It is inappropriate to use Internet-Drafts as reference
80    material or to cite them other than as "work in progress."
81
82NEW:
83
84    This document is a product of the Internet Engineering Task Force
85    (IETF).  It represents the consensus of the IETF community.  It has
86    received public review and has been approved for publication by the
87    Internet Engineering Steering Group (IESG).  Further information on
88    Internet Standards is available in Section 2 of RFC 5741.
89
90
91INTRODUCTION, paragraph 8:
92OLD:
93
94    This Internet-Draft will expire on November 8, 2014.
95
96NEW:
97
98    Information about the current status of this document, any errata,
99    and how to provide feedback on it may be obtained at
100    http://www.rfc-editor.org/info/rfc7230.
101
102
103Section 11., paragraph 0:
104OLD:
105
106    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
107      1.1.  Requirements Notation  . . . . . . . . . . . . . . . . . .  6
108      1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  6
109    2.  Architecture . . . . . . . . . . . . . . . . . . . . . . . . .  6
110      2.1.  Client/Server Messaging  . . . . . . . . . . . . . . . . .  7
111      2.2.  Implementation Diversity . . . . . . . . . . . . . . . . .  8
112      2.3.  Intermediaries . . . . . . . . . . . . . . . . . . . . . .  9
113      2.4.  Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11
114      2.5.  Conformance and Error Handling . . . . . . . . . . . . . . 12
115      2.6.  Protocol Versioning  . . . . . . . . . . . . . . . . . . . 13
116      2.7.  Uniform Resource Identifiers . . . . . . . . . . . . . . . 16
117        2.7.1.  http URI Scheme  . . . . . . . . . . . . . . . . . . . 16
118        2.7.2.  https URI Scheme . . . . . . . . . . . . . . . . . . . 18
119        2.7.3.  http and https URI Normalization and Comparison  . . . 19
120 
121    3.  Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19
122      3.1.  Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20
123        3.1.1.  Request Line . . . . . . . . . . . . . . . . . . . . . 21
124        3.1.2.  Status Line  . . . . . . . . . . . . . . . . . . . . . 22
125      3.2.  Header Fields  . . . . . . . . . . . . . . . . . . . . . . 22
126        3.2.1.  Field Extensibility  . . . . . . . . . . . . . . . . . 23
127        3.2.2.  Field Order  . . . . . . . . . . . . . . . . . . . . . 23
128        3.2.3.  Whitespace . . . . . . . . . . . . . . . . . . . . . . 24
129        3.2.4.  Field Parsing  . . . . . . . . . . . . . . . . . . . . 25
130        3.2.5.  Field Limits . . . . . . . . . . . . . . . . . . . . . 26
131        3.2.6.  Field Value Components . . . . . . . . . . . . . . . . 26
132      3.3.  Message Body . . . . . . . . . . . . . . . . . . . . . . . 27
133        3.3.1.  Transfer-Encoding  . . . . . . . . . . . . . . . . . . 28
134        3.3.2.  Content-Length . . . . . . . . . . . . . . . . . . . . 30
135        3.3.3.  Message Body Length  . . . . . . . . . . . . . . . . . 31
136      3.4.  Handling Incomplete Messages . . . . . . . . . . . . . . . 33
137      3.5.  Message Parsing Robustness . . . . . . . . . . . . . . . . 34
138    4.  Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 35
139      4.1.  Chunked Transfer Coding  . . . . . . . . . . . . . . . . . 35
140        4.1.1.  Chunk Extensions . . . . . . . . . . . . . . . . . . . 36
141        4.1.2.  Chunked Trailer Part . . . . . . . . . . . . . . . . . 36
142        4.1.3.  Decoding Chunked . . . . . . . . . . . . . . . . . . . 37
143      4.2.  Compression Codings  . . . . . . . . . . . . . . . . . . . 38
144        4.2.1.  Compress Coding  . . . . . . . . . . . . . . . . . . . 38
145        4.2.2.  Deflate Coding . . . . . . . . . . . . . . . . . . . . 38
146        4.2.3.  Gzip Coding  . . . . . . . . . . . . . . . . . . . . . 38
147      4.3.  TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
148      4.4.  Trailer  . . . . . . . . . . . . . . . . . . . . . . . . . 39
149    5.  Message Routing  . . . . . . . . . . . . . . . . . . . . . . . 40
150      5.1.  Identifying a Target Resource  . . . . . . . . . . . . . . 40
151      5.2.  Connecting Inbound . . . . . . . . . . . . . . . . . . . . 40
152      5.3.  Request Target . . . . . . . . . . . . . . . . . . . . . . 41
153        5.3.1.  origin-form  . . . . . . . . . . . . . . . . . . . . . 41
154        5.3.2.  absolute-form  . . . . . . . . . . . . . . . . . . . . 42
155        5.3.3.  authority-form . . . . . . . . . . . . . . . . . . . . 42
156        5.3.4.  asterisk-form  . . . . . . . . . . . . . . . . . . . . 42
157      5.4.  Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
158      5.5.  Effective Request URI  . . . . . . . . . . . . . . . . . . 44
159      5.6.  Associating a Response to a Request  . . . . . . . . . . . 46
160      5.7.  Message Forwarding . . . . . . . . . . . . . . . . . . . . 46
161        5.7.1.  Via  . . . . . . . . . . . . . . . . . . . . . . . . . 47
162        5.7.2.  Transformations  . . . . . . . . . . . . . . . . . . . 48
163    6.  Connection Management  . . . . . . . . . . . . . . . . . . . . 49
164      6.1.  Connection . . . . . . . . . . . . . . . . . . . . . . . . 50
165      6.2.  Establishment  . . . . . . . . . . . . . . . . . . . . . . 51
166      6.3.  Persistence  . . . . . . . . . . . . . . . . . . . . . . . 52
167        6.3.1.  Retrying Requests  . . . . . . . . . . . . . . . . . . 53
168        6.3.2.  Pipelining . . . . . . . . . . . . . . . . . . . . . . 53
169 
170      6.4.  Concurrency  . . . . . . . . . . . . . . . . . . . . . . . 54
171      6.5.  Failures and Timeouts  . . . . . . . . . . . . . . . . . . 54
172      6.6.  Tear-down  . . . . . . . . . . . . . . . . . . . . . . . . 55
173      6.7.  Upgrade  . . . . . . . . . . . . . . . . . . . . . . . . . 56
174    7.  ABNF List Extension: #rule . . . . . . . . . . . . . . . . . . 58
175    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 60
176      8.1.  Header Field Registration  . . . . . . . . . . . . . . . . 60
177      8.2.  URI Scheme Registration  . . . . . . . . . . . . . . . . . 60
178      8.3.  Internet Media Type Registration . . . . . . . . . . . . . 61
179        8.3.1.  Internet Media Type message/http . . . . . . . . . . . 61
180        8.3.2.  Internet Media Type application/http . . . . . . . . . 62
181      8.4.  Transfer Coding Registry . . . . . . . . . . . . . . . . . 63
182        8.4.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 63
183        8.4.2.  Registration . . . . . . . . . . . . . . . . . . . . . 64
184      8.5.  Content Coding Registration  . . . . . . . . . . . . . . . 64
185      8.6.  Upgrade Token Registry . . . . . . . . . . . . . . . . . . 65
186        8.6.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 65
187        8.6.2.  Upgrade Token Registration . . . . . . . . . . . . . . 66
188    9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 66
189      9.1.  Establishing Authority . . . . . . . . . . . . . . . . . . 66
190      9.2.  Risks of Intermediaries  . . . . . . . . . . . . . . . . . 67
191      9.3.  Attacks via Protocol Element Length  . . . . . . . . . . . 68
192      9.4.  Response Splitting . . . . . . . . . . . . . . . . . . . . 68
193      9.5.  Request Smuggling  . . . . . . . . . . . . . . . . . . . . 69
194      9.6.  Message Integrity  . . . . . . . . . . . . . . . . . . . . 69
195      9.7.  Message Confidentiality  . . . . . . . . . . . . . . . . . 70
196      9.8.  Privacy of Server Log Information  . . . . . . . . . . . . 70
197    10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 71
198    11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
199      11.1. Normative References . . . . . . . . . . . . . . . . . . . 72
200      11.2. Informative References . . . . . . . . . . . . . . . . . . 74
201    Appendix A.  HTTP Version History  . . . . . . . . . . . . . . . . 76
202      A.1.  Changes from HTTP/1.0  . . . . . . . . . . . . . . . . . . 77
203        A.1.1.  Multi-homed Web Servers  . . . . . . . . . . . . . . . 77
204        A.1.2.  Keep-Alive Connections . . . . . . . . . . . . . . . . 77
205        A.1.3.  Introduction of Transfer-Encoding  . . . . . . . . . . 78
206      A.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 78
207    Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 80
208    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
209
210NEW:
211
212    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
213      1.1.  Requirements Notation  . . . . . . . . . . . . . . . . . .  6
214      1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  6
215    2.  Architecture . . . . . . . . . . . . . . . . . . . . . . . . .  6
216      2.1.  Client/Server Messaging  . . . . . . . . . . . . . . . . .  7
217      2.2.  Implementation Diversity . . . . . . . . . . . . . . . . .  8
218      2.3.  Intermediaries . . . . . . . . . . . . . . . . . . . . . .  9
219      2.4.  Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11
220      2.5.  Conformance and Error Handling . . . . . . . . . . . . . . 12
221      2.6.  Protocol Versioning  . . . . . . . . . . . . . . . . . . . 13
222      2.7.  Uniform Resource Identifiers . . . . . . . . . . . . . . . 16
223        2.7.1.  http URI Scheme  . . . . . . . . . . . . . . . . . . . 16
224        2.7.2.  https URI Scheme . . . . . . . . . . . . . . . . . . . 18
225        2.7.3.  http and https URI Normalization and Comparison  . . . 19
226    3.  Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19
227      3.1.  Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20
228        3.1.1.  Request Line . . . . . . . . . . . . . . . . . . . . . 21
229        3.1.2.  Status Line  . . . . . . . . . . . . . . . . . . . . . 22
230      3.2.  Header Fields  . . . . . . . . . . . . . . . . . . . . . . 22
231        3.2.1.  Field Extensibility  . . . . . . . . . . . . . . . . . 23
232        3.2.2.  Field Order  . . . . . . . . . . . . . . . . . . . . . 23
233        3.2.3.  Whitespace . . . . . . . . . . . . . . . . . . . . . . 24
234        3.2.4.  Field Parsing  . . . . . . . . . . . . . . . . . . . . 25
235        3.2.5.  Field Limits . . . . . . . . . . . . . . . . . . . . . 26
236        3.2.6.  Field Value Components . . . . . . . . . . . . . . . . 26
237      3.3.  Message Body . . . . . . . . . . . . . . . . . . . . . . . 27
238        3.3.1.  Transfer-Encoding  . . . . . . . . . . . . . . . . . . 28
239        3.3.2.  Content-Length . . . . . . . . . . . . . . . . . . . . 30
240        3.3.3.  Message Body Length  . . . . . . . . . . . . . . . . . 31
241      3.4.  Handling Incomplete Messages . . . . . . . . . . . . . . . 33
242      3.5.  Message Parsing Robustness . . . . . . . . . . . . . . . . 34
243    4.  Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 35
244      4.1.  Chunked Transfer Coding  . . . . . . . . . . . . . . . . . 35
245        4.1.1.  Chunk Extensions . . . . . . . . . . . . . . . . . . . 36
246        4.1.2.  Chunked Trailer Part . . . . . . . . . . . . . . . . . 36
247        4.1.3.  Decoding Chunked . . . . . . . . . . . . . . . . . . . 37
248      4.2.  Compression Codings  . . . . . . . . . . . . . . . . . . . 38
249        4.2.1.  Compress Coding  . . . . . . . . . . . . . . . . . . . 38
250        4.2.2.  Deflate Coding . . . . . . . . . . . . . . . . . . . . 38
251        4.2.3.  Gzip Coding  . . . . . . . . . . . . . . . . . . . . . 38
252      4.3.  TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
253      4.4.  Trailer  . . . . . . . . . . . . . . . . . . . . . . . . . 39
254    5.  Message Routing  . . . . . . . . . . . . . . . . . . . . . . . 40
255      5.1.  Identifying a Target Resource  . . . . . . . . . . . . . . 40
256      5.2.  Connecting Inbound . . . . . . . . . . . . . . . . . . . . 40
257      5.3.  Request Target . . . . . . . . . . . . . . . . . . . . . . 41
258        5.3.1.  origin-form  . . . . . . . . . . . . . . . . . . . . . 41
259        5.3.2.  absolute-form  . . . . . . . . . . . . . . . . . . . . 42
260        5.3.3.  authority-form . . . . . . . . . . . . . . . . . . . . 42
261        5.3.4.  asterisk-form  . . . . . . . . . . . . . . . . . . . . 42
262      5.4.  Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
263      5.5.  Effective Request URI  . . . . . . . . . . . . . . . . . . 44
264      5.6.  Associating a Response to a Request  . . . . . . . . . . . 46
265      5.7.  Message Forwarding . . . . . . . . . . . . . . . . . . . . 46
266        5.7.1.  Via  . . . . . . . . . . . . . . . . . . . . . . . . . 47
267        5.7.2.  Transformations  . . . . . . . . . . . . . . . . . . . 48
268    6.  Connection Management  . . . . . . . . . . . . . . . . . . . . 49
269      6.1.  Connection . . . . . . . . . . . . . . . . . . . . . . . . 50
270      6.2.  Establishment  . . . . . . . . . . . . . . . . . . . . . . 51
271      6.3.  Persistence  . . . . . . . . . . . . . . . . . . . . . . . 52
272        6.3.1.  Retrying Requests  . . . . . . . . . . . . . . . . . . 53
273        6.3.2.  Pipelining . . . . . . . . . . . . . . . . . . . . . . 53
274      6.4.  Concurrency  . . . . . . . . . . . . . . . . . . . . . . . 54
275      6.5.  Failures and Timeouts  . . . . . . . . . . . . . . . . . . 54
276      6.6.  Teardown . . . . . . . . . . . . . . . . . . . . . . . . . 55
277      6.7.  Upgrade  . . . . . . . . . . . . . . . . . . . . . . . . . 56
278    7.  ABNF List Extension: #rule . . . . . . . . . . . . . . . . . . 58
279    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 60
280      8.1.  Header Field Registration  . . . . . . . . . . . . . . . . 60
281      8.2.  URI Scheme Registration  . . . . . . . . . . . . . . . . . 60
282      8.3.  Internet Media Type Registration . . . . . . . . . . . . . 61
283        8.3.1.  Internet Media Type message/http . . . . . . . . . . . 61
284        8.3.2.  Internet Media Type application/http . . . . . . . . . 62
285      8.4.  Transfer Coding Registry . . . . . . . . . . . . . . . . . 63
286        8.4.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 63
287        8.4.2.  Registration . . . . . . . . . . . . . . . . . . . . . 64
288      8.5.  Content Coding Registration  . . . . . . . . . . . . . . . 64
289      8.6.  Upgrade Token Registry . . . . . . . . . . . . . . . . . . 65
290        8.6.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 65
291        8.6.2.  Upgrade Token Registration . . . . . . . . . . . . . . 66
292    9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 66
293      9.1.  Establishing Authority . . . . . . . . . . . . . . . . . . 66
294      9.2.  Risks of Intermediaries  . . . . . . . . . . . . . . . . . 67
295      9.3.  Attacks via Protocol Element Length  . . . . . . . . . . . 68
296      9.4.  Response Splitting . . . . . . . . . . . . . . . . . . . . 68
297      9.5.  Request Smuggling  . . . . . . . . . . . . . . . . . . . . 69
298      9.6.  Message Integrity  . . . . . . . . . . . . . . . . . . . . 69
299      9.7.  Message Confidentiality  . . . . . . . . . . . . . . . . . 70
300      9.8.  Privacy of Server Log Information  . . . . . . . . . . . . 70
301    10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 71
302    11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
303      11.1. Normative References . . . . . . . . . . . . . . . . . . . 72
304      11.2. Informative References . . . . . . . . . . . . . . . . . . 74
305    Appendix A.  HTTP Version History  . . . . . . . . . . . . . . . . 76
306      A.1.  Changes from HTTP/1.0  . . . . . . . . . . . . . . . . . . 76
307        A.1.1.  Multihomed Web Servers . . . . . . . . . . . . . . . . 77
308        A.1.2.  Keep-Alive Connections . . . . . . . . . . . . . . . . 77
309        A.1.3.  Introduction of Transfer-Encoding  . . . . . . . . . . 78
310      A.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 78
311    Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 80
312    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
313
314
315Section 1., paragraph 8:
316OLD:
317
318    This HTTP/1.1 specification obsoletes RFC 2616 and RFC 2145 (on HTTP
319    versioning).  This specification also updates the use of CONNECT to
320    establish a tunnel, previously defined in RFC 2817, and defines the
321    "https" URI scheme that was described informally in RFC 2818.
322
323NEW:
324
325    This HTTP/1.1 specification obsoletes [RFC2616] and [RFC2145] (on
326    HTTP versioning).  This specification also updates the use of
327    CONNECT, previously defined in RFC 2817, to establish a tunnel, and
328    defines the "https" URI scheme that was described informally in RFC
329    2818.
330
331
332Section 2.1., paragraph 1:
333OLD:
334
335    HTTP is a stateless request/response protocol that operates by
336    exchanging messages (Section 3) across a reliable transport or
337    session-layer "connection" (Section 6).  An HTTP "client" is a
338    program that establishes a connection to a server for the purpose of
339    sending one or more HTTP requests.  An HTTP "server" is a program
340    that accepts connections in order to service HTTP requests by sending
341    HTTP responses.
342
343NEW:
344
345    HTTP is a stateless request/response protocol that operates by
346    exchanging messages (Section 3) across a reliable transport- or
347    session-layer "connection" (Section 6).  An HTTP "client" is a
348    program that establishes a connection to a server for the purpose of
349    sending one or more HTTP requests.  An HTTP "server" is a program
350    that accepts connections in order to service HTTP requests by sending
351    HTTP responses.
352
353
354Section 2.3., paragraph 7:
355OLD:
356
357    All HTTP requirements applicable to an origin server also apply to
358    the outbound communication of a gateway.  A gateway communicates with
359    inbound servers using any protocol that it desires, including private
360    extensions to HTTP that are outside the scope of this specification.
361    However, an HTTP-to-HTTP gateway that wishes to interoperate with
362    third-party HTTP servers ought to conform to user agent requirements
363    on the gateway's inbound connection.
364
365NEW:
366
367    All HTTP requirements applicable to an origin server also apply to
368    the outbound communication of a gateway.  A gateway communicates with
369    inbound servers using any protocol that it desires, including private
370    extensions to HTTP that are outside the scope of this specification.
371    However, an HTTP-to-HTTP gateway that wishes to interoperate with
372    third-party HTTP servers ought to conform to user-agent requirements
373    on the gateway's inbound connection.
374
375
376Section 2.3., paragraph 11:
377OLD:
378
379    HTTP is defined as a stateless protocol, meaning that each request
380    message can be understood in isolation.  Many implementations depend
381    on HTTP's stateless design in order to reuse proxied connections or
382    dynamically load-balance requests across multiple servers.  Hence, a
383    server MUST NOT assume that two requests on the same connection are
384    from the same user agent unless the connection is secured and
385    specific to that agent.  Some non-standard HTTP extensions (e.g.,
386    [RFC4559]) have been known to violate this requirement, resulting in
387    security and interoperability problems.
388
389NEW:
390
391    HTTP is defined as a stateless protocol, meaning that each request
392    message can be understood in isolation.  Many implementations depend
393    on HTTP's stateless design in order to reuse proxied connections or
394    dynamically load balance requests across multiple servers.  Hence, a
395    server MUST NOT assume that two requests on the same connection are
396    from the same user agent unless the connection is secured and
397    specific to that agent.  Some non-standard HTTP extensions (e.g.,
398    [RFC4559]) have been known to violate this requirement, resulting in
399    security and interoperability problems.
400
401
402Section 2.6., paragraph 2:
403OLD:
404
405    The version of an HTTP message is indicated by an HTTP-version field
406    in the first line of the message.  HTTP-version is case-sensitive.
407
408NEW:
409
410    The version of an HTTP message is indicated by an HTTP-version field
411    in the first line of the message.  HTTP-version is case sensitive.
412
413
414Section 2.6., paragraph 3:
415OLD:
416
417      HTTP-version  = HTTP-name "/" DIGIT "." DIGIT
418      HTTP-name     = %x48.54.54.50 ; "HTTP", case-sensitive
419
420NEW:
421
422      HTTP-version  = HTTP-name "/" DIGIT "." DIGIT
423      HTTP-name     = %x48.54.54.50 ; "HTTP", case sensitive
424
425
426Section 2.6., paragraph 7:
427OLD:
428
429    New header fields can be introduced without changing the protocol
430    version if their defined semantics allow them to be safely ignored by
431    recipients that do not recognize them.  Header field extensibility is
432    discussed in Section 3.2.1.
433
434NEW:
435
436    New header fields can be introduced without changing the protocol
437    version if their defined semantics allow them to be safely ignored by
438    recipients that do not recognize them.  Header-field extensibility is
439    discussed in Section 3.2.1.
440
441
442Section 2.6., paragraph 14:
443OLD:
444
445    When an HTTP message is received with a major version number that the
446    recipient implements, but a higher minor version number than what the
447    recipient implements, the recipient SHOULD process the message as if
448    it were in the highest minor version within that major version to
449    which the recipient is conformant.  A recipient can assume that a
450    message with a higher minor version, when sent to a recipient that
451    has not yet indicated support for that higher version, is
452    sufficiently backwards-compatible to be safely processed by any
453    implementation of the same major version.
454
455NEW:
456
457    When an HTTP message is received with a major version number that the
458    recipient implements, but a higher minor version number than what the
459    recipient implements, the recipient SHOULD process the message as if
460    it were in the highest minor version within that major version to
461    which the recipient is conformant.  A recipient can assume that a
462    message with a higher minor version, when sent to a recipient that
463    has not yet indicated support for that higher version, is
464    sufficiently backwards compatible to be safely processed by any
465    implementation of the same major version.
466
467
468Section 2.7., paragraph 2:
469OLD:
470
471    The definitions of "URI-reference", "absolute-URI", "relative-part",
472    "scheme", "authority", "port", "host", "path-abempty", "segment",
473    "query", and "fragment" are adopted from the URI generic syntax.  An
474    "absolute-path" rule is defined for protocol elements that can
475    contain a non-empty path component.  (This rule differs slightly from
476    RFC 3986's path-abempty rule, which allows for an empty path to be
477    used in references, and path-absolute rule, which does not allow
478    paths that begin with "//".)  A "partial-URI" rule is defined for
479    protocol elements that can contain a relative URI but not a fragment
480    component.
481
482NEW:
483
484    The definitions of "URI-reference", "absolute-URI", "relative-part",
485    "scheme", "authority", "port", "host", "path-abempty", "segment",
486    "query", and "fragment" are adopted from the URI generic syntax.  An
487    "absolute-path" rule is defined for protocol elements that can
488    contain a non-empty path component.  (This rule differs slightly from
489    the path-abempty rule of RFC 3986, which allows for an empty path to
490    be used in references, and path-absolute rule, which does not allow
491    paths that begin with "//".)  A "partial-URI" rule is defined for
492    protocol elements that can contain a relative URI but not a fragment
493    component.
494
495
496Section 2.7.1., paragraph 1:
497OLD:
498
499    The "http" URI scheme is hereby defined for the purpose of minting
500    identifiers according to their association with the hierarchical
501    namespace governed by a potential HTTP origin server listening for
502    TCP ([RFC0793]) connections on a given port.
503
504NEW:
505
506    The "http" URI scheme is hereby defined for the purpose of minting
507    identifiers according to their association with the hierarchical
508    namespace governed by a potential HTTP origin server listening for
509    TCP ([RFC793]) connections on a given port.
510
511
512Section 2.1, paragraph 0:
513OLD:
514
515    If the port is equal to the default port for a scheme, the normal
516    form is to omit the port subcomponent.  When not being used in
517    absolute form as the request target of an OPTIONS request, an empty
518    path component is equivalent to an absolute path of "/", so the
519    normal form is to provide a path of "/" instead.  The scheme and host
520    are case-insensitive and normally provided in lowercase; all other
521    components are compared in a case-sensitive manner.  Characters other
522    than those in the "reserved" set are equivalent to their percent-
523    encoded octets: the normal form is to not encode them (see Sections
524    2.1 and 2.2 of [RFC3986]).
525
526NEW:
527
528    If the port is equal to the default port for a scheme, the normal
529    form is to omit the port subcomponent.  When not being used in
530    absolute form as the request target of an OPTIONS request, an empty
531    path component is equivalent to an absolute path of "/", so the
532    normal form is to provide a path of "/" instead.  The scheme and host
533    are case insensitive and normally provided in lowercase; all other
534    components are compared in a case-sensitive manner.  Characters other
535    than those in the "reserved" set are equivalent to their percent-
536    encoded octets: the normal form is to not encode them (see Sections
537    2.1 and 2.2 of [RFC3986]).
538
539
540Section 3.1., paragraph 2:
541OLD:
542
543    In theory, a client could receive requests and a server could receive
544    responses, distinguishing them by their different start-line formats,
545    but, in practice, servers are implemented to only expect a request (a
546    response is interpreted as an unknown or invalid request method) and
547    clients are implemented to only expect a response.
548
549NEW:
550
551    In theory, a client could receive requests and a server could receive
552    responses, distinguishing them by their different start-line formats,
553    but, in practice, servers are implemented only to expect a request (a
554    response is interpreted as an unknown or invalid request method) and
555    clients are implemented to only expect a response.
556
557
558Section 3.1.1., paragraph 1:
559OLD:
560
561    A request-line begins with a method token, followed by a single space
562    (SP), the request-target, another single space (SP), the protocol
563    version, and ending with CRLF.
564
565NEW:
566
567    A request-line begins with a method token and is followed by a single
568    space (SP), the request-target, another single space (SP), the
569    protocol version, and ends with CRLF.
570
571
572Section 3.1.1., paragraph 3:
573OLD:
574
575    The method token indicates the request method to be performed on the
576    target resource.  The request method is case-sensitive.
577
578NEW:
579
580    The method token indicates the request method to be performed on the
581    target resource.  The request method is case sensitive.
582
583
584Section 3.1.2., paragraph 1:
585OLD:
586
587    The first line of a response message is the status-line, consisting
588    of the protocol version, a space (SP), the status code, another
589    space, a possibly empty textual phrase describing the status code,
590    and ending with CRLF.
591
592NEW:
593
594    The first line of a response message is the status-line, consisting
595    of the protocol version, a space (SP), the status code, another space
596    (SP), a possibly empty textual phrase describing the status code,
597    and, finally, CRLF.
598
599
600Section 3.2.1., paragraph 4:
601OLD:
602
603    All defined header fields ought to be registered with IANA in the
604    Message Header Field Registry, as described in Section 8.3 of
605    [RFC7231].
606
607NEW:
608
609    All defined header fields ought to be registered with IANA in the
610    "Message Headers" field registry, as described in Section 8.3 of
611    [RFC7231].
612
613
614Section 3.2.2., paragraph 4:
615OLD:
616
617       Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
618       appears multiple times in a response message and does not use the
619       list syntax, violating the above requirements on multiple header
620       fields with the same name.  Since it cannot be combined into a
621       single field-value, recipients ought to handle "Set-Cookie" as a
622       special case while processing header fields.  (See Appendix A.2.3
623       of [Kri2001] for details.)
624
625NEW:
626
627       Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
628       appears multiple times in a response message and does not use the
629       list syntax, violating the above requirements on multiple header
630       fields with the same name.  Since it cannot be combined into a
631       single field-value, recipients ought to handle Set-Cookie as a
632       special case while processing header fields.  (See Appendix A.2.3
633       of [Kri2001] for details.)
634
635
636Section 3.2.3., paragraph 2:
637OLD:
638
639    The OWS rule is used where zero or more linear whitespace octets
640    might appear.  For protocol elements where optional whitespace is
641    preferred to improve readability, a sender SHOULD generate the
642    optional whitespace as a single SP; otherwise, a sender SHOULD NOT
643    generate optional whitespace except as needed to white-out invalid or
644    unwanted protocol elements during in-place message filtering.
645
646NEW:
647
648    The OWS rule is used where zero or more linear whitespace octets
649    might appear.  For protocol elements where optional whitespace is
650    preferred to improve readability, a sender SHOULD generate the
651    optional whitespace as a single SP; otherwise, a sender SHOULD NOT
652    generate optional whitespace except as needed to white out invalid or
653    unwanted protocol elements during in-place message filtering.
654
655
656Section 3.2.4., paragraph 1:
657OLD:
658
659    Messages are parsed using a generic algorithm, independent of the
660    individual header field names.  The contents within a given field
661    value are not parsed until a later stage of message interpretation
662    (usually after the message's entire header section has been
663    processed).  Consequently, this specification does not use ABNF rules
664    to define each "Field-Name: Field Value" pair, as was done in
665    previous editions.  Instead, this specification uses ABNF rules that
666    are named according to each registered field name, wherein the rule
667    defines the valid grammar for that field's corresponding field values
668    (i.e., after the field-value has been extracted from the header
669    section by a generic field parser).
670
671NEW:
672
673    Messages are parsed using a generic algorithm, independent of the
674    individual header field names.  The contents within a given field
675    value are not parsed until a later stage of message interpretation
676    (usually after the message's entire header section has been
677    processed).  Consequently, this specification does not use ABNF rules
678    to define each "field-name: field-value" pair, as was done in
679    previous editions.  Instead, this specification uses ABNF rules that
680    are named according to each registered field name, wherein the rule
681    defines the valid grammar for that field's corresponding field values
682    (i.e., after the field-value has been extracted from the header
683    section by a generic field parser).
684
685
686Section 3.2.4., paragraph 8:
687OLD:
688
689    Historically, HTTP has allowed field content with text in the
690    ISO-8859-1 charset [ISO-8859-1], supporting other charsets only
691    through use of [RFC2047] encoding.  In practice, most HTTP header
692    field values use only a subset of the US-ASCII charset [USASCII].
693    Newly defined header fields SHOULD limit their field values to
694    US-ASCII octets.  A recipient SHOULD treat other octets in field
695    content (obs-text) as opaque data.
696
697NEW:
698
699    Historically, HTTP has allowed field content with text in the
700    ISO-8859-1 [ISO-8859-1] charset, supporting other charsets only
701    through use of [RFC2047] encoding.  In practice, most HTTP header
702    field values use only a subset of the US-ASCII charset [USASCII].
703    Newly defined header fields SHOULD limit their field values to
704    US-ASCII octets.  A recipient SHOULD treat other octets in field
705    content (obs-text) as opaque data.
706
707
708Section 7., paragraph 1:
709OLD:
710
711    Since there is no way to distinguish a successfully completed, close-
712    delimited message from a partially-received message interrupted by
713    network failure, a server SHOULD generate encoding or length-
714    delimited messages whenever possible.  The close-delimiting feature
715    exists primarily for backwards compatibility with HTTP/1.0.
716
717NEW:
718
719    Since there is no way to distinguish a successfully completed, close-
720    delimited message from a partially received message interrupted by
721    network failure, a server SHOULD generate encoding or length-
722    delimited messages whenever possible.  The close-delimiting feature
723    exists primarily for backwards compatibility with HTTP/1.0.
724
725
726Section 4., paragraph 5:
727OLD:
728
729    All transfer-coding names are case-insensitive and ought to be
730    registered within the HTTP Transfer Coding registry, as defined in
731    Section 8.4.  They are used in the TE (Section 4.3) and Transfer-
732    Encoding (Section 3.3.1) header fields.
733
734NEW:
735
736    All transfer-coding names are case insensitive and ought to be
737    registered within the "HTTP Transfer Coding" registry, as defined in
738    Section 8.4.  They are used in the TE (Section 4.3) and Transfer-
739    Encoding (Section 3.3.1) header fields.
740
741
742Section 5.7.2., paragraph 6:
743OLD:
744
745    A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of
746    a message that contains a no-transform cache-control directive
747    (Section 5.2 of [RFC7234]).
748
749NEW:
750
751    A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of
752    a message that contains a no-transform Cache-Control directive
753    (Section 5.2 of [RFC7234]).
754
755
756Section 200, paragraph 0:
757OLD:
758
759    A proxy MAY transform the payload of a message that does not contain
760    a no-transform cache-control directive.  A proxy that transforms a
761    payload MUST add a Warning header field with the warn-code of 214
762    ("Transformation Applied") if one is not already in the message (see
763    Section 5.5 of [RFC7234]).  A proxy that transforms the payload of a
764    200 (OK) response can further inform downstream recipients that a
765    transformation has been applied by changing the response status code
766    to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).
767
768NEW:
769
770    A proxy MAY transform the payload of a message that does not contain
771    a no-transform Cache-Control directive.  A proxy that transforms a
772    payload MUST add a Warning header field with the warn-code of 214
773    ("Transformation Applied") if one is not already in the message (see
774    Section 5.5 of [RFC7234]).  A proxy that transforms the payload of a
775    200 (OK) response can further inform downstream recipients that a
776    transformation has been applied by changing the response status code
777    to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).
778
779
780Section 6., paragraph 1:
781OLD:
782
783    HTTP messaging is independent of the underlying transport or session-
784    layer connection protocol(s).  HTTP only presumes a reliable
785    transport with in-order delivery of requests and the corresponding
786    in-order delivery of responses.  The mapping of HTTP request and
787    response structures onto the data units of an underlying transport
788    protocol is outside the scope of this specification.
789
790NEW:
791
792    HTTP messaging is independent of the underlying transport- or
793    session-layer connection protocol(s).  HTTP only presumes a reliable
794    transport with in-order delivery of requests and the corresponding
795    in-order delivery of responses.  The mapping of HTTP request and
796    response structures onto the data units of an underlying transport
797    protocol is outside the scope of this specification.
798
799
800Section 6.1., paragraph 6:
801OLD:
802
803    Connection options are case-insensitive.
804
805NEW:
806
807    Connection options are case insensitive.
808
809
810Section 6.2., paragraph 1:
811OLD:
812
813    It is beyond the scope of this specification to describe how
814    connections are established via various transport or session-layer
815    protocols.  Each connection applies to only one transport link.
816
817NEW:
818
819    It is beyond the scope of this specification to describe how
820    connections are established via various transport- or session-layer
821    protocols.  Each connection applies to only one transport link.
822
823
824Section 6.3., paragraph 1:
825OLD:
826
827    HTTP/1.1 defaults to the use of "persistent connections", allowing
828    multiple requests and responses to be carried over a single
829    connection.  The "close" connection-option is used to signal that a
830    connection will not persist after the current request/response.  HTTP
831    implementations SHOULD support persistent connections.
832
833NEW:
834
835    HTTP/1.1 defaults to the use of "persistent connections", allowing
836    multiple requests and responses to be carried over a single
837    connection.  The "close" connection option is used to signal that a
838    connection will not persist after the current request/response.  HTTP
839    implementations SHOULD support persistent connections.
840
841
842Section 6.3., paragraph 3:
843OLD:
844
845    o  If the close connection option is present, the connection will not
846       persist after the current response; else,
847
848NEW:
849
850    o  If the "close" connection option is present, the connection will
851       not persist after the current response; else,
852
853
854Section 6.3., paragraph 7:
855OLD:
856
857    A client MAY send additional requests on a persistent connection
858    until it sends or receives a close connection option or receives an
859    HTTP/1.0 response without a "keep-alive" connection option.
860
861NEW:
862
863    A client MAY send additional requests on a persistent connection
864    until it sends or receives a "close" connection option or receives an
865    HTTP/1.0 response without a "keep-alive" connection option.
866
867
868Section 6.5., paragraph 6:
869OLD:
870
871 6.6.  Tear-down
872
873NEW:
874
875 6.6.  Teardown
876
877
878Section 6.5., paragraph 8:
879OLD:
880
881    A client that sends a close connection option MUST NOT send further
882    requests on that connection (after the one containing close) and MUST
883    close the connection after reading the final response message
884    corresponding to this request.
885
886NEW:
887
888    A client that sends a "close" connection option MUST NOT send further
889    requests on that connection (after the one containing close) and MUST
890    close the connection after reading the final response message
891    corresponding to this request.
892
893
894Section 6.5., paragraph 9:
895OLD:
896
897    A server that receives a close connection option MUST initiate a
898    close of the connection (see below) after it sends the final response
899    to the request that contained close.  The server SHOULD send a close
900    connection option in its final response on that connection.  The
901    server MUST NOT process any further requests received on that
902    connection.
903
904NEW:
905
906    A server that receives a "close" connection option MUST initiate a
907    close of the connection (see below) after it sends the final response
908    to the request that contained close.  The server SHOULD send a close
909    connection option in its final response on that connection.  The
910    server MUST NOT process any further requests received on that
911    connection.
912
913
914Section 6.5., paragraph 10:
915OLD:
916
917    A server that sends a close connection option MUST initiate a close
918    of the connection (see below) after it sends the response containing
919    close.  The server MUST NOT process any further requests received on
920    that connection.
921
922NEW:
923
924    A server that sends a "close" connection option MUST initiate a close
925    of the connection (see below) after it sends the response containing
926    close.  The server MUST NOT process any further requests received on
927    that connection.
928
929
930Section 6.5., paragraph 11:
931OLD:
932
933    A client that receives a close connection option MUST cease sending
934    requests on that connection and close the connection after reading
935    the response message containing the close; if additional pipelined
936    requests had been sent on the connection, the client SHOULD NOT
937    assume that they will be processed by the server.
938
939NEW:
940
941    A client that receives a "close" connection option MUST cease sending
942    requests on that connection and close the connection after reading
943    the response message containing the close; if additional pipelined
944    requests had been sent on the connection, the client SHOULD NOT
945    assume that they will be processed by the server.
946
947
948Section 6.7., paragraph 9:
949OLD:
950
951    The capabilities and nature of the application-level communication
952    after the protocol change is entirely dependent upon the new
953    protocol(s) chosen.  However, immediately after sending the 101
954    response, the server is expected to continue responding to the
955    original request as if it had received its equivalent within the new
956    protocol (i.e., the server still has an outstanding request to
957    satisfy after the protocol has been changed, and is expected to do so
958    without requiring the request to be repeated).
959
960NEW:
961
962    The capabilities and nature of the application-level communication
963    after the protocol change is entirely dependent upon the new
964    protocol(s) chosen.  However, immediately after sending the 101
965    (Switching Protocols) response, the server is expected to continue
966    responding to the original request as if it had received its
967    equivalent within the new protocol (i.e., the server still has an
968    outstanding request to satisfy after the protocol has been changed,
969    and is expected to do so without requiring the request to be
970    repeated).
971
972
973Section 7., paragraph 14:
974OLD:
975
976    Then the following are valid values for example-list (not including
977    the double quotes, which are present for delimitation only):
978
979NEW:
980
981    Then, the following are valid values for example-list (not including
982    the double quotes, which are present for delimitation only):
983
984
985Section 8.1., paragraph 1:
986OLD:
987
988    HTTP header fields are registered within the Message Header Field
989    Registry maintained at
990    <http://www.iana.org/assignments/message-headers/>.
991
992NEW:
993
994    HTTP header fields are registered within the "Message Header" field
995    registry maintained at
996    <http://www.iana.org/assignments/message-headers/>.
997
998
999Section 8.1., paragraph 2:
1000OLD:
1001
1002    This document defines the following HTTP header fields, so their
1003    associated registry entries has been updated according to the
1004    permanent registrations below (see [BCP90]):
1005
1006NEW:
1007
1008    This document defines the following HTTP header fields, so the
1009    "Permanent Message Header Field Names" registry has been updated
1010    accordingly (see [BCP90]).
1011
1012
1013Section 8.2., paragraph 2:
1014OLD:
1015
1016    This document defines the following URI schemes, so their associated
1017    registry entries has been updated according to the permanent
1018    registrations below:
1019
1020NEW:
1021
1022    This document defines the following URI schemes, so the "Permanent
1023    URI Schemes" registry has been updated accordingly.
1024
1025
1026Section 8.4., paragraph 1:
1027OLD:
1028
1029    The HTTP Transfer Coding Registry defines the namespace for transfer
1030    coding names.  It is maintained at
1031    <http://www.iana.org/assignments/http-parameters>.
1032
1033NEW:
1034
1035    The "HTTP Transfer Coding" registry defines the namespace for
1036    transfer coding names.  It is maintained at
1037    <http://www.iana.org/assignments/http-parameters>.
1038
1039
1040Section 8.4.2., paragraph 1:
1041OLD:
1042
1043    The HTTP Transfer Coding Registry has been updated with the
1044    registrations below:
1045
1046NEW:
1047
1048    The "HTTP Transfer Coding Registry" has been updated with the
1049    registrations below:
1050
1051
1052Section 8.5., paragraph 1:
1053OLD:
1054
1055    IANA maintains the registry of HTTP Content Codings at
1056    <http://www.iana.org/assignments/http-parameters>.
1057
1058NEW:
1059
1060    IANA maintains the "HTTP Content Coding Registry" at
1061    <http://www.iana.org/assignments/http-parameters>.
1062
1063
1064Section 8.5., paragraph 2:
1065OLD:
1066
1067    The HTTP Content Codings Registry has been updated with the
1068    registrations below:
1069
1070NEW:
1071
1072    The "HTTP Content Codings Registry" has been updated with the
1073    registrations below:
1074
1075
1076Section 8.6., paragraph 1:
1077OLD:
1078
1079    The HTTP Upgrade Token Registry defines the namespace for protocol-
1080    name tokens used to identify protocols in the Upgrade header field.
1081    The registry is maintained at
1082    <http://www.iana.org/assignments/http-upgrade-tokens>.
1083
1084NEW:
1085
1086    The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
1087    defines the namespace for protocol-name tokens used to identify
1088    protocols in the Upgrade header field.  The registry is maintained at
1089    <http://www.iana.org/assignments/http-upgrade-tokens>.
1090
1091
1092Section 8.6.2., paragraph 1:
1093OLD:
1094
1095    The "HTTP" entry in the HTTP Upgrade Token Registry has been updated
1096    with the registration below:
1097
1098NEW:
1099
1100    The "HTTP" entry in the "HTTP Upgrade Token" registry shall be
1101    updated with the registration below:
1102
1103
1104Section 9.1., paragraph 3:
1105OLD:
1106
1107    When a registered name is used in the authority component, the "http"
1108    URI scheme (Section 2.7.1) relies on the user's local name resolution
1109    service to determine where it can find authoritative responses.  This
1110    means that any attack on a user's network host table, cached names,
1111    or name resolution libraries becomes an avenue for attack on
1112    establishing authority.  Likewise, the user's choice of server for
1113    Domain Name Service (DNS), and the hierarchy of servers from which it
1114    obtains resolution results, could impact the authenticity of address
1115    mappings; DNS Security Extensions (DNSSEC, [RFC4033]) are one way to
1116    improve authenticity.
1117
1118NEW:
1119
1120    When a registered name is used in the authority component, the "http"
1121    URI scheme (Section 2.7.1) relies on the user's local name resolution
1122    service to determine where it can find authoritative responses.  This
1123    means that any attack on a user's network host table, cached names,
1124    or name resolution libraries becomes an avenue for attack on
1125    establishing authority.  Likewise, the user's choice of server for
1126    Domain Name Service (DNS), and the hierarchy of servers from which it
1127    obtains resolution results, could impact the authenticity of address
1128    mappings; DNS Security Extensions (DNSSEC) ([RFC4033]) is one way to
1129    improve authenticity.
1130
1131
1132Section 9.2., paragraph 1:
1133OLD:
1134
1135    By their very nature, HTTP intermediaries are men-in-the-middle, and
1136    thus represent an opportunity for man-in-the-middle attacks.
1137    Compromise of the systems on which the intermediaries run can result
1138    in serious security and privacy problems.  Intermediaries might have
1139    access to security-related information, personal information about
1140    individual users and organizations, and proprietary information
1141    belonging to users and content providers.  A compromised
1142    intermediary, or an intermediary implemented or configured without
1143    regard to security and privacy considerations, might be used in the
1144    commission of a wide range of potential attacks.
1145
1146NEW:
1147
1148    By their very nature, HTTP intermediaries are men in the middle and,
1149    thus, represent an opportunity for man-in-the-middle attacks.
1150    Compromise of the systems on which the intermediaries run can result
1151    in serious security and privacy problems.  Intermediaries might have
1152    access to security-related information, personal information about
1153    individual users and organizations, and proprietary information
1154    belonging to users and content providers.  A compromised
1155    intermediary, or an intermediary implemented or configured without
1156    regard to security and privacy considerations, might be used in the
1157    commission of a wide range of potential attacks.
1158
1159
1160Section 9.6., paragraph 2:
1161OLD:
1162
1163    User agents are encouraged to implement configurable means for
1164    detecting and reporting failures of message integrity such that those
1165    means can be enabled within environments for which integrity is
1166    necessary.  For example, a browser being used to view medical history
1167    or drug interaction information needs to indicate to the user when
1168    such information is detected by the protocol to be incomplete,
1169    expired, or corrupted during transfer.  Such mechanisms might be
1170    selectively enabled via user agent extensions or the presence of
1171    message integrity metadata in a response.  At a minimum, user agents
1172    ought to provide some indication that allows a user to distinguish
1173    between a complete and incomplete response message (Section 3.4) when
1174    such verification is desired.
1175
1176NEW:
1177
1178    User agents are encouraged to implement configurable means for
1179    detecting and reporting failures of message integrity such that those
1180    means can be enabled within environments for which integrity is
1181    necessary.  For example, a browser being used to view medical history
1182    or drug interaction information needs to indicate to the user when
1183    such information is detected by the protocol to be incomplete,
1184    expired, or corrupted during transfer.  Such mechanisms might be
1185    selectively enabled via user-agent extensions or the presence of
1186    message integrity metadata in a response.  At a minimum, user agents
1187    ought to provide some indication that allows a user to distinguish
1188    between a complete and incomplete response message (Section 3.4) when
1189    such verification is desired.
1190
1191
1192Section 11.1., paragraph 1:
1193OLD:
1194
1195    [RFC0793]     Postel, J., "Transmission Control Protocol", STD 7,
1196                  RFC 793, September 1981.
1197 
1198    [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
1199                  Format Specification version 3.3", RFC 1950, May 1996.
1200
1201NEW:
1202
1203    [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
1204                  Format Specification version 3.3", RFC 1950, May 1996.
1205
1206
1207Section 11.1., paragraph 7:
1208OLD:
1209
1210    [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1211                  Transfer Protocol (HTTP/1.1): Semantics and Content",
1212                  draft-ietf-httpbis-p2-semantics-latest (work in
1213                  progress), May 2014.
1214
1215NEW:
1216
1217    [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1218                  Transfer Protocol (HTTP/1.1): Semantics and Content",
1219                  RFC 7231, May 2014.
1220
1221
1222Section 11.1., paragraph 8:
1223OLD:
1224
1225    [RFC7232]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1226                  Transfer Protocol (HTTP/1.1): Conditional Requests",
1227                  draft-ietf-httpbis-p4-conditional-latest (work in
1228                  progress), May 2014.
1229
1230NEW:
1231
1232    [RFC7232]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1233                  Transfer Protocol (HTTP/1.1): Conditional Requests",
1234                  RFC 7232, May 2014.
1235
1236
1237Section 11.1., paragraph 9:
1238OLD:
1239
1240    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1241                  "Hypertext Transfer Protocol (HTTP/1.1): Range
1242                  Requests", draft-ietf-httpbis-p5-range-latest (work in
1243                  progress), May 2014.
1244
1245NEW:
1246
1247    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1248                  "Hypertext Transfer Protocol (HTTP/1.1): Range
1249                  Requests", RFC 7233, May 2014.
1250
1251
1252Section 11.1., paragraph 10:
1253OLD:
1254
1255    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1256                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1257                  draft-ietf-httpbis-p6-cache-latest (work in progress),
1258                  May 2014.
1259
1260NEW:
1261
1262    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1263                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1264                  RFC 7234, May 2014.
1265
1266
1267Section 11.1., paragraph 11:
1268OLD:
1269
1270    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1271                  Transfer Protocol (HTTP/1.1): Authentication",
1272                  draft-ietf-httpbis-p7-auth-latest (work in progress),
1273                  May 2014.
1274
1275NEW:
1276
1277    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
1278                  Transfer Protocol (HTTP/1.1): Authentication",
1279                  RFC 7235, May 2014.
1280 
1281    [RFC793]      Postel, J., "Transmission Control Protocol", STD 7,
1282                  RFC 793, September 1981.
1283
1284
1285Appendix A., paragraph 7:
1286OLD:
1287
1288 A.1.1.  Multi-homed Web Servers
1289
1290NEW:
1291
1292 A.1.1.  Multihomed Web Servers
1293
1294
1295Section 19.7.1, paragraph 8:
1296OLD:
1297
1298    HTTP's approach to error handling has been explained.  (Section 2.5)
1299
1300NEW:
1301
1302    HTTP's approach to error handling has been explained (Section 2.5).
1303
1304
1305Section 19.7.1, paragraph 9:
1306OLD:
1307
1308    The HTTP-version ABNF production has been clarified to be case-
1309    sensitive.  Additionally, version numbers have been restricted to
1310    single digits, due to the fact that implementations are known to
1311    handle multi-digit version numbers incorrectly.  (Section 2.6)
1312
1313NEW:
1314
1315    The HTTP-version ABNF production has been clarified to be case
1316    sensitive.  Additionally, version numbers have been restricted to
1317    single digits, due to the fact that implementations are known to
1318    handle multi-digit version numbers incorrectly (Section 2.6).
1319
1320
1321Section 19.7.1, paragraph 10:
1322OLD:
1323
1324    Userinfo (i.e., username and password) are now disallowed in HTTP and
1325    HTTPS URIs, because of security issues related to their transmission
1326    on the wire.  (Section 2.7.1)
1327
1328NEW:
1329
1330    Userinfo (i.e., username and password) are now disallowed in HTTP and
1331    HTTPS URIs, because of security issues related to their transmission
1332    on the wire (Section 2.7.1).
1333
1334
1335Section 19.7.1, paragraph 11:
1336OLD:
1337
1338    The HTTPS URI scheme is now defined by this specification;
1339    previously, it was done in Section 2.4 of [RFC2818].  Furthermore, it
1340    implies end-to-end security.  (Section 2.7.2)
1341
1342NEW:
1343
1344    The HTTPS URI scheme is now defined by this specification;
1345    previously, it was defined in Section 2.4 of [RFC2818].  Furthermore,
1346    it implies end-to-end security (Section 2.7.2).
1347
1348
1349Section 19.7.1, paragraph 12:
1350OLD:
1351
1352    HTTP messages can be (and often are) buffered by implementations;
1353    despite it sometimes being available as a stream, HTTP is
1354    fundamentally a message-oriented protocol.  Minimum supported sizes
1355    for various protocol elements have been suggested, to improve
1356    interoperability.  (Section 3)
1357
1358NEW:
1359
1360    HTTP messages can be (and often are) buffered by implementations;
1361    despite it sometimes being available as a stream, HTTP is
1362    fundamentally a message-oriented protocol.  Minimum supported sizes
1363    for various protocol elements have been suggested, to improve
1364    interoperability (Section 3).
1365
1366
1367Section 19.7.1, paragraph 13:
1368OLD:
1369
1370    Invalid whitespace around field-names is now required to be rejected,
1371    because accepting it represents a security vulnerability.  The ABNF
1372    productions defining header fields now only list the field value.
1373    (Section 3.2)
1374
1375NEW:
1376
1377    Invalid whitespace around field-names is now required to be rejected,
1378    because accepting it represents a security vulnerability.  The ABNF
1379    productions defining header fields now only list the field value
1380    (Section 3.2).
1381
1382
1383Section 19.7.1, paragraph 14:
1384OLD:
1385
1386    Rules about implicit linear whitespace between certain grammar
1387    productions have been removed; now whitespace is only allowed where
1388    specifically defined in the ABNF.  (Section 3.2.3)
1389
1390NEW:
1391
1392    Rules about implicit linear whitespace between certain grammar
1393    productions have been removed; now whitespace is only allowed where
1394    specifically defined in the ABNF (Section 3.2.3).
1395
1396
1397Section 19.7.1, paragraph 15:
1398OLD:
1399
1400    Header fields that span multiple lines ("line folding") are
1401    deprecated.  (Section 3.2.4)
1402    The NUL octet is no longer allowed in comment and quoted-string text,
1403    and handling of backslash-escaping in them has been clarified.  The
1404    quoted-pair rule no longer allows escaping control characters other
1405    than HTAB.  Non-ASCII content in header fields and the reason phrase
1406    has been obsoleted and made opaque (the TEXT rule was removed).
1407    (Section 3.2.6)
1408
1409NEW:
1410
1411    Header fields that span multiple lines ("line folding") are
1412    deprecated (Section 3.2.4).
1413 
1414    The NUL octet is no longer allowed in comment and quoted-string text,
1415    and handling of backslash-escaping in them has been clarified.  The
1416    quoted-pair rule no longer allows escaping control characters other
1417    than HTAB.  Non-US-ASCII content in header fields and the reason
1418    phrase has been obsoleted and made opaque (the TEXT rule was removed)
1419    (Section 3.2.6).
1420
1421
1422Section 19.7.1, paragraph 16:
1423OLD:
1424
1425    Bogus "Content-Length" header fields are now required to be handled
1426    as errors by recipients.  (Section 3.3.2)
1427
1428NEW:
1429
1430    Bogus "Content-Length" header fields are now required to be handled
1431    as errors by recipients (Section 3.3.2).
1432
1433
1434Section 19.7.1, paragraph 17:
1435OLD:
1436
1437    The algorithm for determining the message body length has been
1438    clarified to indicate all of the special cases (e.g., driven by
1439    methods or status codes) that affect it, and that new protocol
1440    elements cannot define such special cases.  CONNECT is a new, special
1441    case in determining message body length. "multipart/byteranges" is no
1442    longer a way of determining message body length detection.
1443    (Section 3.3.3)
1444
1445NEW:
1446
1447    The algorithm for determining the message body length has been
1448    clarified to indicate all of the special cases (e.g., driven by
1449    methods or status codes) that affect it, and that new protocol
1450    elements cannot define such special cases.  CONNECT is a new, special
1451    case in determining message body length. "multipart/byteranges" is no
1452    longer a way of determining message body length detection
1453    (Section 3.3.3).
1454
1455
1456Section 19.7.1, paragraph 18:
1457OLD:
1458
1459    The "identity" transfer coding token has been removed.  (Sections 3.3
1460    and 4)
1461
1462NEW:
1463
1464    The "identity" transfer coding token has been removed (Sections 3.3
1465    and 4).
1466
1467
1468Section 19.7.1, paragraph 19:
1469OLD:
1470
1471    Chunk length does not include the count of the octets in the chunk
1472    header and trailer.  Line folding in chunk extensions is disallowed.
1473    (Section 4.1)
1474
1475NEW:
1476
1477    Chunk length does not include the count of the octets in the chunk
1478    header and trailer.  Line folding in chunk extensions is disallowed
1479    (Section 4.1).
1480
1481
1482Section 19.7.1, paragraph 20:
1483OLD:
1484
1485    The meaning of the "deflate" content coding has been clarified.
1486    (Section 4.2.2)
1487
1488NEW:
1489
1490    The meaning of the "deflate" content coding has been clarified
1491    (Section 4.2.2).
1492
1493
1494Section 19.7.1, paragraph 21:
1495OLD:
1496
1497    The segment + query components of RFC 3986 have been used to define
1498    the request-target, instead of abs_path from RFC 1808.  The asterisk-
1499    form of the request-target is only allowed with the OPTIONS method.
1500    (Section 5.3)
1501
1502NEW:
1503
1504    The segment + query components of RFC 3986 have been used to define
1505    the request-target, instead of abs_path from RFC 1808.  The asterisk-
1506    form of the request-target is only allowed with the OPTIONS method
1507    (Section 5.3).
1508
1509
1510Section 19.7.1, paragraph 22:
1511OLD:
1512
1513    The term "Effective Request URI" has been introduced.  (Section 5.5)
1514
1515NEW:
1516
1517    The term "Effective Request URI" has been introduced (Section 5.5).
1518
1519
1520Section 19.7.1, paragraph 23:
1521OLD:
1522
1523    Gateways do not need to generate Via header fields anymore.
1524    (Section 5.7.1)
1525
1526NEW:
1527
1528    Gateways do not need to generate Via header fields anymore
1529    (Section 5.7.1).
1530
1531
1532Section 19.7.1, paragraph 24:
1533OLD:
1534
1535    Exactly when "close" connection options have to be sent has been
1536    clarified.  Also, "hop-by-hop" header fields are required to appear
1537    in the Connection header field; just because they're defined as hop-
1538    by-hop in this specification doesn't exempt them.  (Section 6.1)
1539
1540NEW:
1541
1542    Exactly when "close" connection options have to be sent has been
1543    clarified.  Also, "hop-by-hop" header fields are required to appear
1544    in the Connection header field; just because they're defined as hop-
1545    by-hop in this specification doesn't exempt them (Section 6.1).
1546
1547
1548Section 19.7.1, paragraph 25:
1549OLD:
1550
1551    The limit of two connections per server has been removed.  An
1552    idempotent sequence of requests is no longer required to be retried.
1553    The requirement to retry requests under certain circumstances when
1554    the server prematurely closes the connection has been removed.  Also,
1555    some extraneous requirements about when servers are allowed to close
1556    connections prematurely have been removed.  (Section 6.3)
1557
1558NEW:
1559
1560    The limit of two connections per server has been removed.  An
1561    idempotent sequence of requests is no longer required to be retried.
1562    The requirement to retry requests under certain circumstances when
1563    the server prematurely closes the connection has been removed.  Also,
1564    some extraneous requirements about when servers are allowed to close
1565    connections prematurely have been removed (Section 6.3).
1566
1567
1568Section 19.7.1, paragraph 26:
1569OLD:
1570
1571    The semantics of the Upgrade header field is now defined in responses
1572    other than 101 (this was incorporated from [RFC2817]).  Furthermore,
1573    the ordering in the field value is now significant.  (Section 6.7)
1574
1575NEW:
1576
1577    The semantics of the Upgrade header field is now defined in responses
1578    other than 101 (this was incorporated from [RFC2817]).  Furthermore,
1579    the ordering in the field value is now significant (Section 6.7).
1580
1581
1582Section 19.7.1, paragraph 27:
1583OLD:
1584
1585    Empty list elements in list productions (e.g., a list header field
1586    containing ", ,") have been deprecated.  (Section 7)
1587
1588NEW:
1589
1590    Empty list elements in list productions (e.g., a list header field
1591    containing ", ,") have been deprecated (Section 7).
1592
1593
1594Section 19.7.1, paragraph 28:
1595OLD:
1596
1597    Registration of Transfer Codings now requires IETF Review
1598    (Section 8.4)
1599
1600NEW:
1601
1602    Registration of Transfer Codings now requires IETF Review
1603    (Section 8.4).
1604
1605
1606Section 19.7.1, paragraph 29:
1607OLD:
1608
1609    This specification now defines the Upgrade Token Registry, previously
1610    defined in Section 7.2 of [RFC2817].  (Section 8.6)
1611
1612NEW:
1613
1614    This specification now defines the "HTTP Upgrade Tokens" registry,
1615    previously defined in Section 7.2 of [RFC2817] (Section 8.6).
1616
1617
1618Section 19.7.1, paragraph 30:
1619OLD:
1620
1621    The expectation to support HTTP/0.9 requests has been removed.
1622    (Appendix A)
1623
1624NEW:
1625
1626    The expectation to support HTTP/0.9 requests has been removed
1627    (Appendix A).
1628
1629
1630Section 19.7.1, paragraph 31:
1631OLD:
1632
1633    Issues with the Keep-Alive and Proxy-Connection header fields in
1634    requests are pointed out, with use of the latter being discouraged
1635    altogether.  (Appendix A.1.2)
1636
1637NEW:
1638
1639    Issues with the Keep-Alive and Proxy-Connection header fields in
1640    requests are pointed out, with use of the latter being discouraged
1641    altogether (Appendix A.1.2).
1642
1643
1644Appendix B., paragraph 7:
1645OLD:
1646
1647    URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
1648    Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
1649    Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
1650     ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
1651     comment ] ) ] )
1652
1653NEW:
1654
1655    URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
1656    Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
1657 
1658    Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
1659     ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
1660     comment ] ) ] )
1661
1662
1663Appendix B., paragraph 15:
1664OLD:
1665
1666    partial-URI = relative-part [ "?" query ]
1667    path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
1668    port = <port, defined in [RFC3986], Section 3.2.3>
1669    protocol = protocol-name [ "/" protocol-version ]
1670    protocol-name = token
1671    protocol-version = token
1672    pseudonym = token
1673 
1674    qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
1675     / %x5D-7E ; ']'-'~'
1676     / obs-text
1677    query = <query, defined in [RFC3986], Section 3.4>
1678    quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
1679    quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
1680
1681NEW:
1682
1683    partial-URI = relative-part [ "?" query ]
1684    path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
1685    port = <port, defined in [RFC3986], Section 3.2.3>
1686    protocol = protocol-name [ "/" protocol-version ]
1687    protocol-name = token
1688    protocol-version = token
1689    pseudonym = token
1690    qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
1691     / %x5D-7E ; ']'-'~'
1692     / obs-text
1693    query = <query, defined in [RFC3986], Section 3.4>
1694    quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
1695    quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
1696
1697
1698Appendix B., paragraph 24:
1699OLD:
1700
1701    D
1702       deflate (Coding Format)  38
1703       Delimiters  26
1704       downstream  9
1705
1706NEW:
1707
1708    D
1709       deflate (Coding Format)  38
1710       Delimiters  26
1711       downstream  10
1712
1713
1714Appendix B., paragraph 26:
1715OLD:
1716
1717    G
1718       gateway  10
1719       Grammar
1720          absolute-form  41-42
1721          absolute-path  16
1722          absolute-URI  16
1723          ALPHA  6
1724          asterisk-form  41-42
1725          authority  16
1726          authority-form  41-42
1727          BWS  24
1728          chunk  35
1729          chunk-data  35
1730          chunk-ext  35-36
1731          chunk-ext-name  36
1732          chunk-ext-val  36
1733          chunk-size  35
1734          chunked-body  35-36
1735          comment  27
1736          Connection  51
1737          connection-option  51
1738          Content-Length  30
1739          CR  6
1740          CRLF  6
1741          ctext  27
1742          CTL  6
1743          DIGIT  6
1744          DQUOTE  6
1745          field-content  22
1746          field-name  22, 39
1747          field-value  22
1748          field-vchar  22
1749          fragment  16
1750          header-field  22, 36
1751          HEXDIG  6
1752          Host  43
1753          HTAB  6
1754          HTTP-message  19
1755          HTTP-name  13
1756          http-URI  16
1757          HTTP-version  13
1758          https-URI  18
1759          last-chunk  35
1760          LF  6
1761          message-body  27
1762          method  21
1763          obs-fold  22
1764          obs-text  27
1765          OCTET  6
1766          origin-form  41
1767          OWS  24
1768          partial-URI  16
1769          port  16
1770          protocol-name  47
1771          protocol-version  47
1772          pseudonym  47
1773          qdtext  27
1774          query  16
1775          quoted-pair  27
1776          quoted-string  27
1777          rank  38
1778          reason-phrase  22
1779          received-by  47
1780          received-protocol  47
1781          request-line  21
1782          request-target  41
1783          RWS  24
1784          scheme  16
1785          segment  16
1786          SP  6
1787          start-line  20
1788          status-code  22
1789          status-line  22
1790          t-codings  38
1791          t-ranking  38
1792          tchar  27
1793          TE  38
1794          token  27
1795          Trailer  39
1796          trailer-part  35-36
1797          transfer-coding  35
1798          Transfer-Encoding  28
1799          transfer-extension  35
1800          transfer-parameter  35
1801          Upgrade  56
1802          uri-host  16
1803          URI-reference  16
1804          VCHAR  6
1805          Via  47
1806       gzip (Coding Format)  38
1807
1808NEW:
1809
1810    G
1811       gateway  10
1812       Grammar
1813          absolute-form  41-42
1814          absolute-path  16
1815          absolute-URI  16
1816          ALPHA  6
1817          asterisk-form  41-42
1818          authority  16
1819          authority-form  41-42
1820          BWS  24
1821          chunk  35
1822          chunk-data  35
1823          chunk-ext  35-36
1824          chunk-ext-name  36
1825          chunk-ext-val  36
1826          chunk-size  35
1827          chunked-body  35-36
1828          comment  27
1829          Connection  51
1830          connection-option  51
1831          Content-Length  30
1832          CR  6
1833          CRLF  6
1834          ctext  27
1835          CTL  6
1836          DIGIT  6
1837          DQUOTE  6
1838          field-content  22
1839          field-name  22, 39
1840          field-value  22
1841          field-vchar  22
1842          fragment  16
1843          header-field  22, 36
1844          HEXDIG  6
1845          Host  43
1846          HTAB  6
1847          HTTP-message  19
1848          HTTP-name  14
1849          http-URI  16
1850          HTTP-version  14
1851          https-URI  18
1852          last-chunk  35
1853          LF  6
1854          message-body  27
1855          method  21
1856          obs-fold  22
1857          obs-text  27
1858          OCTET  6
1859          origin-form  41
1860          OWS  24
1861          partial-URI  16
1862          port  16
1863          protocol-name  47
1864          protocol-version  47
1865          pseudonym  47
1866          qdtext  27
1867          query  16
1868          quoted-pair  27
1869          quoted-string  27
1870          rank  38
1871          reason-phrase  22
1872          received-by  47
1873          received-protocol  47
1874          request-line  21
1875          request-target  41
1876          RWS  24
1877          scheme  16
1878          segment  16
1879          SP  6
1880          start-line  20
1881          status-code  22
1882          status-line  22
1883          t-codings  38
1884          t-ranking  38
1885          tchar  27
1886          TE  38
1887          token  27
1888          Trailer  39
1889          trailer-part  35-36
1890          transfer-coding  35
1891          Transfer-Encoding  28
1892          transfer-extension  35
1893          transfer-parameter  35
1894          Upgrade  56
1895          uri-host  16
1896          URI-reference  16
1897          VCHAR  6
1898          Via  47
1899       gzip (Coding Format)  38
1900
1901
1902Appendix B., paragraph 28:
1903OLD:
1904
1905    I
1906       inbound  9
1907       interception proxy  11
1908       intermediary  9
1909
1910NEW:
1911
1912    I
1913       inbound  10
1914       interception proxy  11
1915       intermediary  9
1916
1917
1918Appendix B., paragraph 31:
1919OLD:
1920
1921    O
1922       origin server  7
1923       origin-form (of request-target)  41
1924       outbound  9
1925
1926NEW:
1927
1928    O
1929       origin server  7
1930       origin-form (of request-target)  41
1931       outbound  10
1932
1933
1934Appendix B., paragraph 36:
1935OLD:
1936
1937    U
1938       Upgrade header field  56
1939       upstream  9
1940       URI scheme
1941          http  16
1942          https  18
1943       user agent  7
1944
1945NEW:
1946
1947    U
1948       Upgrade header field  56
1949       upstream  10
1950       URI scheme
1951          http  16
1952          https  18
1953       user agent  7
1954
1955
1956Section 345, paragraph 1:
1957OLD:
1958
1959    EMail: fielding@gbiv.com
1960    URI:   http://roy.gbiv.com/
1961 
1962    Julian F. Reschke (editor)
1963    greenbytes GmbH
1964    Hafenweg 16
1965    Muenster, NW  48155
1966    Germany
1967
1968NEW:
1969
1970    EMail: fielding@gbiv.com
1971    URI:   http://roy.gbiv.com/
1972    Julian F. Reschke (editor)
1973    greenbytes GmbH
1974    Hafenweg 16
1975    Muenster, NW  48155
1976    Germany
1977
Note: See TracBrowser for help on using the repository browser.