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

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

revert changes for auth48 boilerplate checks (#553)

  • Property svn:eol-style set to native
File size: 54.4 KB
Line 
1
2INTRODUCTION, paragraph 1:
3OLD:
4
5 HTTPbis Working Group                                   R. Fielding, Ed.
6 Internet-Draft                                                     Adobe
7 Obsoletes: 2145, 2616                                    J. Reschke, Ed.
8 (if approved)                                                 greenbytes
9 Updates: 2817, 2818 (if approved)                           June 6, 2014
10 Intended status: Standards Track
11 Expires: December 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                                      June 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 December 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
103INTRODUCTION, paragraph 14:
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  . . . . . . . . . . . . . . . . . . . . 24
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 . . . . . . . . . . . . . . . . . . . . 29
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 . . . . . . . . . . . . . . . . . . . . . . . 34
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  . . . . . . . . . . . . . . . . . . . 37
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  . . . . . . . . . . . . . . . . . . . . . . . 39
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  . . . . . . . . . . . . . . . . . . . . 41
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  . . . . . . . . . . . . . . . . . . . . . . . . . 46
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  . . . . . . . . . . . . . . . . . . . . . . . 51
167        6.3.1.  Retrying Requests  . . . . . . . . . . . . . . . . . . 52
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  . . . . . . . . . . . . . . . . . . . . . 59
176      8.1.  Header Field Registration  . . . . . . . . . . . . . . . . 59
177      8.2.  URI Scheme Registration  . . . . . . . . . . . . . . . . . 60
178      8.3.  Internet Media Type Registration . . . . . . . . . . . . . 60
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 . . . . . . . . . . . . . . . . . . 64
186        8.6.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 65
187        8.6.2.  Upgrade Token Registration . . . . . . . . . . . . . . 65
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  . . . . . . . . . . . 67
192      9.4.  Response Splitting . . . . . . . . . . . . . . . . . . . . 68
193      9.5.  Request Smuggling  . . . . . . . . . . . . . . . . . . . . 69
194      9.6.  Message Integrity  . . . . . . . . . . . . . . . . . . . . 69
195      9.7.  Message Confidentiality  . . . . . . . . . . . . . . . . . 69
196      9.8.  Privacy of Server Log Information  . . . . . . . . . . . . 70
197    10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 70
198    11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
199      11.1. Normative References . . . . . . . . . . . . . . . . . . . 72
200      11.2. Informative References . . . . . . . . . . . . . . . . . . 73
201    Appendix A.  HTTP Version History  . . . . . . . . . . . . . . . . 75
202      A.1.  Changes from HTTP/1.0  . . . . . . . . . . . . . . . . . . 76
203        A.1.1.  Multihomed Web Servers . . . . . . . . . . . . . . . . 76
204        A.1.2.  Keep-Alive Connections . . . . . . . . . . . . . . . . 77
205        A.1.3.  Introduction of Transfer-Encoding  . . . . . . . . . . 77
206      A.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 77
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 ....................................17
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 .............................27
237       3.3. Message Body ..............................................28
238            3.3.1. Transfer-Encoding ..................................28
239            3.3.2. Content-Length .....................................30
240            3.3.3. Message Body Length ................................32
241       3.4. Handling Incomplete Messages ..............................34
242       3.5. Message Parsing Robustness ................................34
243    4. Transfer Codings ...............................................35
244       4.1. Chunked Transfer Coding ...................................36
245            4.1.1. Chunk Extensions ...................................36
246            4.1.2. Chunked Trailer Part ...............................37
247            4.1.3. Decoding Chunked ...................................38
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 ........................................39
252       4.3. TE ........................................................39
253       4.4. Trailer ...................................................40
254    5. Message Routing ................................................40
255       5.1. Identifying a Target Resource .............................40
256       5.2. Connecting Inbound ........................................41
257       5.3. Request Target ............................................41
258            5.3.1. origin-form ........................................42
259            5.3.2. absolute-form ......................................42
260            5.3.3. authority-form .....................................43
261            5.3.4. asterisk-form ......................................43
262       5.4. Host ......................................................44
263       5.5. Effective Request URI .....................................45
264       5.6. Associating a Response to a Request .......................46
265       5.7. Message Forwarding ........................................47
266            5.7.1. Via ................................................47
267            5.7.2. Transformations ....................................49
268    6. Connection Management ..........................................50
269       6.1. Connection ................................................51
270       6.2. Establishment .............................................52
271       6.3. Persistence ...............................................52
272            6.3.1. Retrying Requests ..................................53
273            6.3.2. Pipelining .........................................54
274       6.4. Concurrency ...............................................55
275       6.5. Failures and Timeouts .....................................55
276       6.6. Tear-down .................................................56
277       6.7. Upgrade ...................................................57
278    7. ABNF List Extension: #rule .....................................59
279    8. IANA Considerations ............................................61
280       8.1. Header Field Registration .................................61
281       8.2. URI Scheme Registration ...................................62
282       8.3. Internet Media Type Registration ..........................62
283            8.3.1. Internet Media Type message/http ...................62
284            8.3.2. Internet Media Type application/http ...............63
285       8.4. Transfer Coding Registry ..................................64
286            8.4.1. Procedure ..........................................65
287            8.4.2. Registration .......................................65
288       8.5. Content Coding Registration ...............................66
289       8.6. Upgrade Token Registry ....................................66
290            8.6.1. Procedure ..........................................66
291            8.6.2. Upgrade Token Registration .........................67
292    9. Security Considerations ........................................67
293       9.1. Establishing Authority ....................................67
294       9.2. Risks of Intermediaries ...................................68
295       9.3. Attacks via Protocol Element Length .......................69
296       9.4. Response Splitting ........................................69
297       9.5. Request Smuggling .........................................70
298       9.6. Message Integrity .........................................70
299       9.7. Message Confidentiality ...................................71
300       9.8. Privacy of Server Log Information .........................71
301    10. Acknowledgments ...............................................72
302    11. References ....................................................74
303       11.1. Normative References .....................................74
304       11.2. Informative References ...................................75
305    Appendix A. HTTP Version History ..................................78
306       A.1. Changes from HTTP/1.0  ....................................78
307            A.1.1.  Multihomed Web Servers ............................78
308            A.1.2.  Keep-Alive Connections ............................79
309            A.1.3.  Introduction of Transfer-Encoding .................79
310       A.2.  Changes from RFC 2616 ....................................80
311    Appendix B. Collected ABNF ........................................82
312    Index .............................................................85
313
314
315Section 2.1., paragraph 4:
316OLD:
317
318    Most HTTP communication consists of a retrieval request (GET) for a
319    representation of some resource identified by a URI.  In the simplest
320    case, this might be accomplished via a single bidirectional
321    connection (===) between the user agent (UA) and the origin server
322    (O).
323
324NEW:
325
326    Most HTTP communication consists of a retrieval request (GET) for a
327    representation of some resource identified by a URI.  In the simplest
328    case, this might be accomplished via a single bidirectional
329    connection (===) between the user agent (UA) and the origin
330    server (O).
331
332
333Section 2.5., paragraph 5:
334OLD:
335
336    When a received protocol element is parsed, the recipient MUST be
337    able to parse any value of reasonable length that is applicable to
338    the recipient's role and that matches the grammar defined by the
339    corresponding ABNF rules.  Note, however, that some received protocol
340    elements might not be parsed.  For example, an intermediary
341    forwarding a message might parse a header-field into generic field-
342    name and field-value components, but then forward the header field
343    without further parsing inside the field-value.
344
345NEW:
346
347    When a received protocol element is parsed, the recipient MUST be
348    able to parse any value of reasonable length that is applicable to
349    the recipient's role and that matches the grammar defined by the
350    corresponding ABNF rules.  Note, however, that some received protocol
351    elements might not be parsed.  For example, an intermediary
352    forwarding a message might parse a header-field into generic
353    field-name and field-value components, but then forward the header
354    field without further parsing inside the field-value.
355
356
357Section 2.5., paragraph 8:
358OLD:
359
360    A recipient MUST interpret a received protocol element according to
361    the semantics defined for it by this specification, including
362    extensions to this specification, unless the recipient has determined
363    (through experience or configuration) that the sender incorrectly
364    implements what is implied by those semantics.  For example, an
365    origin server might disregard the contents of a received Accept-
366    Encoding header field if inspection of the User-Agent header field
367    indicates a specific implementation version that is known to fail on
368    receipt of certain content codings.
369
370NEW:
371
372    A recipient MUST interpret a received protocol element according to
373    the semantics defined for it by this specification, including
374    extensions to this specification, unless the recipient has determined
375    (through experience or configuration) that the sender incorrectly
376    implements what is implied by those semantics.  For example, an
377    origin server might disregard the contents of a received
378    Accept-Encoding header field if inspection of the User-Agent header
379    field indicates a specific implementation version that is known to
380    fail on receipt of certain content codings.
381
382
383Section 2.6., paragraph 8:
384OLD:
385
386    Intermediaries that process HTTP messages (i.e., all intermediaries
387    other than those acting as tunnels) MUST send their own HTTP-version
388    in forwarded messages.  In other words, they are not allowed to
389    blindly forward the first line of an HTTP message without ensuring
390    that the protocol version in that message matches a version to which
391    that intermediary is conformant for both the receiving and sending of
392    messages.  Forwarding an HTTP message without rewriting the HTTP-
393    version might result in communication errors when downstream
394    recipients use the message sender's version to determine what
395    features are safe to use for later communication with that sender.
396
397NEW:
398
399    Intermediaries that process HTTP messages (i.e., all intermediaries
400    other than those acting as tunnels) MUST send their own HTTP-version
401    in forwarded messages.  In other words, they are not allowed to
402    blindly forward the first line of an HTTP message without ensuring
403    that the protocol version in that message matches a version to which
404    that intermediary is conformant for both the receiving and sending of
405    messages.  Forwarding an HTTP message without rewriting the
406    HTTP-version might result in communication errors when downstream
407    recipients use the message sender's version to determine what
408    features are safe to use for later communication with that sender.
409
410
411Section 2.7., paragraph 5:
412OLD:
413
414    Each protocol element in HTTP that allows a URI reference will
415    indicate in its ABNF production whether the element allows any form
416    of reference (URI-reference), only a URI in absolute form (absolute-
417    URI), only the path and optional query components, or some
418    combination of the above.  Unless otherwise indicated, URI references
419    are parsed relative to the effective request URI (Section 5.5).
420
421NEW:
422
423    Each protocol element in HTTP that allows a URI reference will
424    indicate in its ABNF production whether the element allows any form
425    of reference (URI-reference), only a URI in absolute form
426    (absolute-URI), only the path and optional query components, or some
427    combination of the above.  Unless otherwise indicated, URI references
428    are parsed relative to the effective request URI (Section 5.5).
429
430
431Section 2.7.1., paragraph 2:
432OLD:
433
434      http-URI = "http:" "//" authority path-abempty [ "?" query ]
435 
436                 [ "#" fragment ]
437
438NEW:
439
440      http-URI = "http:" "//" authority path-abempty [ "?" query ]
441                 [ "#" fragment ]
442
443
444Section 2.7.3., paragraph 2:
445OLD:
446
447    If the port is equal to the default port for a scheme, the normal
448    form is to omit the port subcomponent.  When not being used in
449    absolute form as the request target of an OPTIONS request, an empty
450    path component is equivalent to an absolute path of "/", so the
451    normal form is to provide a path of "/" instead.  The scheme and host
452    are case-insensitive and normally provided in lowercase; all other
453    components are compared in a case-sensitive manner.  Characters other
454    than those in the "reserved" set are equivalent to their percent-
455    encoded octets: the normal form is to not encode them (see Sections
456    2.1 and 2.2 of [RFC3986]).
457
458NEW:
459
460    If the port is equal to the default port for a scheme, the normal
461    form is to omit the port subcomponent.  When not being used in
462    absolute form as the request target of an OPTIONS request, an empty
463    path component is equivalent to an absolute path of "/", so the
464    normal form is to provide a path of "/" instead.  The scheme and host
465    are case-insensitive and normally provided in lowercase; all other
466    components are compared in a case-sensitive manner.  Characters other
467    than those in the "reserved" set are equivalent to their
468    percent-encoded octets: the normal form is to not encode them (see
469    Sections 2.1 and 2.2 of [RFC3986]).
470
471
472Section 400, paragraph 1:
473OLD:
474
475    HTTP does not place a predefined limit on the length of a request-
476    line, as described in Section 2.5.  A server that receives a method
477    longer than any that it implements SHOULD respond with a 501 (Not
478    Implemented) status code.  A server that receives a request-target
479    longer than any URI it wishes to parse MUST respond with a 414 (URI
480    Too Long) status code (see Section 6.5.12 of [RFC7231]).
481
482NEW:
483
484    HTTP does not place a predefined limit on the length of a
485    request-line, as described in Section 2.5.  A server that receives a
486    method longer than any that it implements SHOULD respond with a 501
487    (Not Implemented) status code.  A server that receives a
488    request-target longer than any URI it wishes to parse MUST respond
489    with a 414 (URI Too Long) status code (see Section 6.5.12 of
490    [RFC7231]).
491
492
493Section 3.2.4., paragraph 3:
494OLD:
495
496    A field value might be preceded and/or followed by optional
497    whitespace (OWS); a single SP preceding the field-value is preferred
498    for consistent readability by humans.  The field value does not
499    include any leading or trailing whitespace: OWS occurring before the
500    first non-whitespace octet of the field value or after the last non-
501    whitespace octet of the field value ought to be excluded by parsers
502    when extracting the field value from a header field.
503
504NEW:
505
506    A field value might be preceded and/or followed by optional
507    whitespace (OWS); a single SP preceding the field-value is preferred
508    for consistent readability by humans.  The field value does not
509    include any leading or trailing whitespace: OWS occurring before the
510    first non-whitespace octet of the field value or after the last
511    non-whitespace octet of the field value ought to be excluded by
512    parsers when extracting the field value from a header field.
513
514
515Section 3.2.4., paragraph 7:
516OLD:
517
518    A user agent that receives an obs-fold in a response message that is
519    not within a message/http container MUST replace each received obs-
520    fold with one or more SP octets prior to interpreting the field
521    value.
522
523NEW:
524
525    A user agent that receives an obs-fold in a response message that is
526    not within a message/http container MUST replace each received
527    obs-fold with one or more SP octets prior to interpreting the field
528    value.
529
530
531Section 3.3., paragraph 4:
532OLD:
533
534    The presence of a message body in a request is signaled by a Content-
535    Length or Transfer-Encoding header field.  Request message framing is
536    independent of method semantics, even if the method does not define
537    any use for a message body.
538
539NEW:
540
541    The presence of a message body in a request is signaled by a
542    Content-Length or Transfer-Encoding header field.  Request message
543    framing is independent of method semantics, even if the method does
544    not define any use for a message body.
545
546
547Section 3.3.1., paragraph 8:
548OLD:
549
550    Unlike Content-Encoding (Section 3.1.2.1 of [RFC7231]), Transfer-
551    Encoding is a property of the message, not of the representation, and
552    any recipient along the request/response chain MAY decode the
553    received transfer coding(s) or apply additional transfer coding(s) to
554    the message body, assuming that corresponding changes are made to the
555    Transfer-Encoding field-value.  Additional information about the
556    encoding parameters can be provided by other header fields not
557    defined by this specification.
558
559NEW:
560
561    Unlike Content-Encoding (Section 3.1.2.1 of [RFC7231]),
562    Transfer-Encoding is a property of the message, not of the
563    representation, and any recipient along the request/response chain
564    MAY decode the received transfer coding(s) or apply additional
565    transfer coding(s) to the message body, assuming that corresponding
566    changes are made to the Transfer-Encoding field-value.  Additional
567    information about the encoding parameters can be provided by other
568    header fields not defined by this specification.
569
570
571Section 3.3.2., paragraph 10:
572OLD:
573
574    Aside from the cases defined above, in the absence of Transfer-
575    Encoding, an origin server SHOULD send a Content-Length header field
576    when the payload body size is known prior to sending the complete
577    header section.  This will allow downstream recipients to measure
578    transfer progress, know when a received message is complete, and
579    potentially reuse the connection for additional requests.
580
581NEW:
582
583    Aside from the cases defined above, in the absence of
584    Transfer-Encoding, an origin server SHOULD send a Content-Length
585    header field when the payload body size is known prior to sending the
586    complete header section.  This will allow downstream recipients to
587    measure transfer progress, know when a received message is complete,
588    and potentially reuse the connection for additional requests.
589
590
591Section 3.3.2., paragraph 13:
592OLD:
593
594       Note: HTTP's use of Content-Length for message framing differs
595       significantly from the same field's use in MIME, where it is an
596       optional field used only within the "message/external-body" media-
597       type.
598
599NEW:
600
601       Note: HTTP's use of Content-Length for message framing differs
602       significantly from the same field's use in MIME, where it is an
603       optional field used only within the "message/external-body"
604       media-type.
605
606
607Section 7., paragraph 1:
608OLD:
609
610    Since there is no way to distinguish a successfully completed, close-
611    delimited message from a partially received message interrupted by
612    network failure, a server SHOULD generate encoding or length-
613    delimited messages whenever possible.  The close-delimiting feature
614    exists primarily for backwards compatibility with HTTP/1.0.
615
616NEW:
617
618    Since there is no way to distinguish a successfully completed,
619    close-delimited message from a partially received message interrupted
620    by network failure, a server SHOULD generate encoding or
621    length-delimited messages whenever possible.  The close-delimiting
622    feature exists primarily for backwards compatibility with HTTP/1.0.
623
624
625Section 4., paragraph 5:
626OLD:
627
628    All transfer-coding names are case-insensitive and ought to be
629    registered within the HTTP Transfer Coding registry, as defined in
630    Section 8.4.  They are used in the TE (Section 4.3) and Transfer-
631    Encoding (Section 3.3.1) header fields.
632
633NEW:
634
635    All transfer-coding names are case-insensitive and ought to be
636    registered within the HTTP Transfer Coding registry, as defined in
637    Section 8.4.  They are used in the TE (Section 4.3) and
638    Transfer-Encoding (Section 3.3.1) header fields.
639
640
641Section 4.1.1., paragraph 1:
642OLD:
643
644    The chunked encoding allows each chunk to include zero or more chunk
645    extensions, immediately following the chunk-size, for the sake of
646    supplying per-chunk metadata (such as a signature or hash), mid-
647    message control information, or randomization of message body size.
648
649NEW:
650
651    The chunked encoding allows each chunk to include zero or more chunk
652    extensions, immediately following the chunk-size, for the sake of
653    supplying per-chunk metadata (such as a signature or hash),
654    mid-message control information, or randomization of message body
655    size.
656
657
658Section 5.1., paragraph 1:
659OLD:
660
661    HTTP is used in a wide variety of applications, ranging from general-
662    purpose computers to home appliances.  In some cases, communication
663    options are hard-coded in a client's configuration.  However, most
664    HTTP clients rely on the same resource identification mechanism and
665    configuration techniques as general-purpose Web browsers.
666
667NEW:
668
669    HTTP is used in a wide variety of applications, ranging from
670    general-purpose computers to home appliances.  In some cases,
671    communication options are hard-coded in a client's configuration.
672    However, most HTTP clients rely on the same resource identification
673    mechanism and configuration techniques as general-purpose Web
674    browsers.
675
676
677Section 5.4., paragraph 8:
678OLD:
679
680    When a proxy receives a request with an absolute-form of request-
681    target, the proxy MUST ignore the received Host header field (if any)
682    and instead replace it with the host information of the request-
683    target.  A proxy that forwards such a request MUST generate a new
684    Host field-value based on the received request-target rather than
685    forward the received Host field-value.
686
687NEW:
688
689    When a proxy receives a request with an absolute-form of
690    request-target, the proxy MUST ignore the received Host header field
691    (if any) and instead replace it with the host information of the
692    request-target.  A proxy that forwards such a request MUST generate a
693    new Host field-value based on the received request-target rather than
694    forward the received Host field-value.
695
696
697Section 5.6., paragraph 2:
698OLD:
699
700    A client that has more than one outstanding request on a connection
701    MUST maintain a list of outstanding requests in the order sent and
702    MUST associate each received response message on that connection to
703    the highest ordered request that has not yet received a final (non-
704    1xx) response.
705
706NEW:
707
708    A client that has more than one outstanding request on a connection
709    MUST maintain a list of outstanding requests in the order sent and
710    MUST associate each received response message on that connection to
711    the highest ordered request that has not yet received a final
712    (non-1xx) response.
713
714
715Section 6.3.1., paragraph 2:
716OLD:
717
718    When an inbound connection is closed prematurely, a client MAY open a
719    new connection and automatically retransmit an aborted sequence of
720    requests if all of those requests have idempotent methods (Section
721    4.2.2 of [RFC7231]).  A proxy MUST NOT automatically retry non-
722    idempotent requests.
723
724NEW:
725
726    When an inbound connection is closed prematurely, a client MAY open a
727    new connection and automatically retransmit an aborted sequence of
728    requests if all of those requests have idempotent methods (Section
729    4.2.2 of [RFC7231]).  A proxy MUST NOT automatically retry
730    non-idempotent requests.
731
732
733Section 6.4., paragraph 3:
734OLD:
735
736    Multiple connections are typically used to avoid the "head-of-line
737    blocking" problem, wherein a request that takes significant server-
738    side processing and/or has a large payload blocks subsequent requests
739    on the same connection.  However, each connection consumes server
740    resources.  Furthermore, using multiple connections can cause
741    undesirable side effects in congested networks.
742
743NEW:
744
745    Multiple connections are typically used to avoid the "head-of-line
746    blocking" problem, wherein a request that takes significant
747    server-side processing and/or has a large payload blocks subsequent
748    requests on the same connection.  However, each connection consumes
749    server resources.  Furthermore, using multiple connections can cause
750    undesirable side effects in congested networks.
751
752
753Section 7., paragraph 2:
754OLD:
755
756    A construct "#" is defined, similar to "*", for defining comma-
757    delimited lists of elements.  The full form is "<n>#<m>element"
758    indicating at least <n> and at most <m> elements, each separated by a
759    single comma (",") and optional whitespace (OWS).
760
761NEW:
762
763    A construct "#" is defined, similar to "*", for defining
764    comma-delimited lists of elements.  The full form is "<n>#<m>element"
765    indicating at least <n> and at most <m> elements, each separated by a
766    single comma (",") and optional whitespace (OWS).
767
768
769Section 8.3.1., paragraph 17:
770OLD:
771
772       File extension(s):  N/A
773       Macintosh file type code(s):  N/A
774
775NEW:
776
777       File extension(s):  N/A
778 
779       Macintosh file type code(s):  N/A
780
781
782Section 8.3.2., paragraph 12:
783OLD:
784
785    Applications that use this media type:  N/A
786    Fragment identifier considerations:  N/A
787
788NEW:
789
790    Applications that use this media type:  N/A
791 
792    Fragment identifier considerations:  N/A
793
794
795Section 9.1., paragraph 1:
796OLD:
797
798    HTTP relies on the notion of an authoritative response: a response
799    that has been determined by (or at the direction of) the authority
800    identified within the target URI to be the most appropriate response
801    for that request given the state of the target resource at the time
802    of response message origination.  Providing a response from a non-
803    authoritative source, such as a shared cache, is often useful to
804    improve performance and availability, but only to the extent that the
805    source can be trusted or the distrusted response can be safely used.
806
807NEW:
808
809    HTTP relies on the notion of an authoritative response: a response
810    that has been determined by (or at the direction of) the authority
811    identified within the target URI to be the most appropriate response
812    for that request given the state of the target resource at the time
813    of response message origination.  Providing a response from a
814    non-authoritative source, such as a shared cache, is often useful to
815    improve performance and availability, but only to the extent that the
816    source can be trusted or the distrusted response can be safely used.
817
818
819Section 9.6., paragraph 1:
820OLD:
821
822    HTTP does not define a specific mechanism for ensuring message
823    integrity, instead relying on the error-detection ability of
824    underlying transport protocols and the use of length or chunk-
825    delimited framing to detect completeness.  Additional integrity
826    mechanisms, such as hash functions or digital signatures applied to
827    the content, can be selectively added to messages via extensible
828    metadata header fields.  Historically, the lack of a single integrity
829    mechanism has been justified by the informal nature of most HTTP
830    communication.  However, the prevalence of HTTP as an information
831    access mechanism has resulted in its increasing use within
832    environments where verification of message integrity is crucial.
833
834NEW:
835
836    HTTP does not define a specific mechanism for ensuring message
837    integrity, instead relying on the error-detection ability of
838    underlying transport protocols and the use of length or
839    chunk-delimited framing to detect completeness.  Additional integrity
840    mechanisms, such as hash functions or digital signatures applied to
841    the content, can be selectively added to messages via extensible
842    metadata header fields.  Historically, the lack of a single integrity
843    mechanism has been justified by the informal nature of most HTTP
844    communication.  However, the prevalence of HTTP as an information
845    access mechanism has resulted in its increasing use within
846    environments where verification of message integrity is crucial.
847
848
849Section 9.8., paragraph 3:
850OLD:
851
852    To minimize the risk of theft or accidental publication, log
853    information ought to be purged of personally identifiable
854    information, including user identifiers, IP addresses, and user-
855    provided query parameters, as soon as that information is no longer
856    necessary to support operational needs for security, auditing, or
857    fraud control.
858
859NEW:
860
861    To minimize the risk of theft or accidental publication, log
862    information ought to be purged of personally identifiable
863    information, including user identifiers, IP addresses, and
864    user-provided query parameters, as soon as that information is no
865    longer necessary to support operational needs for security, auditing,
866    or fraud control.
867
868
869Section 11.1., paragraph 8:
870OLD:
871
872    [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
873                  Transfer Protocol (HTTP/1.1): Semantics and Content",
874                  draft-ietf-httpbis-p2-semantics-latest (work in
875                  progress), June 2014.
876
877NEW:
878
879    [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
880                  Transfer Protocol (HTTP/1.1): Semantics and Content",
881                  RFC 7231, June 2014.
882
883
884Section 11.1., paragraph 9:
885OLD:
886
887    [RFC7232]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
888                  Transfer Protocol (HTTP/1.1): Conditional Requests",
889                  draft-ietf-httpbis-p4-conditional-latest (work in
890                  progress), June 2014.
891
892NEW:
893
894    [RFC7232]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
895                  Transfer Protocol (HTTP/1.1): Conditional Requests",
896                  RFC 7232, June 2014.
897
898
899Section 11.1., paragraph 10:
900OLD:
901
902    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
903                  "Hypertext Transfer Protocol (HTTP/1.1): Range
904                  Requests", draft-ietf-httpbis-p5-range-latest (work in
905                  progress), June 2014.
906
907NEW:
908
909    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
910                  "Hypertext Transfer Protocol (HTTP/1.1): Range
911                  Requests", RFC 7233, June 2014.
912
913
914Section 11.1., paragraph 11:
915OLD:
916
917    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
918                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
919                  draft-ietf-httpbis-p6-cache-latest (work in progress),
920                  June 2014.
921
922NEW:
923
924    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
925                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
926                  RFC 7234, June 2014.
927
928
929Section 11.1., paragraph 12:
930OLD:
931
932    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
933                  Transfer Protocol (HTTP/1.1): Authentication",
934                  draft-ietf-httpbis-p7-auth-latest (work in progress),
935                  June 2014.
936
937NEW:
938
939    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
940                  Transfer Protocol (HTTP/1.1): Authentication",
941                  RFC 7235, June 2014.
942
943
944Section 19.7.1, paragraph 4:
945OLD:
946
947    Clients are also encouraged to consider the use of Connection: keep-
948    alive in requests carefully; while they can enable persistent
949    connections with HTTP/1.0 servers, clients using them will need to
950    monitor the connection for "hung" requests (which indicate that the
951    client ought stop sending the header field), and this mechanism ought
952    not be used by clients at all when a proxy is being used.
953
954NEW:
955
956    Clients are also encouraged to consider the use of Connection:
957    keep-alive in requests carefully; while they can enable persistent
958    connections with HTTP/1.0 servers, clients using them will need to
959    monitor the connection for "hung" requests (which indicate that the
960    client ought stop sending the header field), and this mechanism ought
961    not be used by clients at all when a proxy is being used.
962
963
964Section 19.7.1, paragraph 9:
965OLD:
966
967    The HTTP-version ABNF production has been clarified to be case-
968    sensitive.  Additionally, version numbers have been restricted to
969    single digits, due to the fact that implementations are known to
970    handle multi-digit version numbers incorrectly.  (Section 2.6)
971    Userinfo (i.e., username and password) are now disallowed in HTTP and
972    HTTPS URIs, because of security issues related to their transmission
973    on the wire.  (Section 2.7.1)
974
975NEW:
976
977    The HTTP-version ABNF production has been clarified to be case-
978    sensitive.  Additionally, version numbers have been restricted to
979    single digits, due to the fact that implementations are known to
980    handle multi-digit version numbers incorrectly.  (Section 2.6)
981 
982    Userinfo (i.e., username and password) are now disallowed in HTTP and
983    HTTPS URIs, because of security issues related to their transmission
984    on the wire.  (Section 2.7.1)
985
986
987Section 19.7.1, paragraph 21:
988OLD:
989
990    The segment + query components of RFC 3986 have been used to define
991    the request-target, instead of abs_path from RFC 1808.  The asterisk-
992    form of the request-target is only allowed with the OPTIONS method.
993    (Section 5.3)
994
995NEW:
996
997    The segment + query components of RFC 3986 have been used to define
998    the request-target, instead of abs_path from RFC 1808.  The
999    asterisk-form of the request-target is only allowed with the OPTIONS
1000    method.  (Section 5.3)
1001
1002
1003Section 19.7.1, paragraph 28:
1004OLD:
1005
1006    Registration of Transfer Codings now requires IETF Review
1007    (Section 8.4)
1008 
1009    This specification now defines the Upgrade Token Registry, previously
1010    defined in Section 7.2 of [RFC2817].  (Section 8.6)
1011
1012NEW:
1013
1014    Registration of Transfer Codings now requires IETF Review
1015    (Section 8.4)
1016    This specification now defines the Upgrade Token Registry, previously
1017    defined in Section 7.2 of [RFC2817].  (Section 8.6)
1018
1019
1020Appendix B., paragraph 2:
1021OLD:
1022
1023    Connection = *( "," OWS ) connection-option *( OWS "," [ OWS
1024     connection-option ] )
1025    Content-Length = 1*DIGIT
1026
1027NEW:
1028
1029    Connection = *( "," OWS ) connection-option *( OWS "," [ OWS
1030     connection-option ] )
1031 
1032    Content-Length = 1*DIGIT
1033
1034
1035Appendix B., paragraph 9:
1036OLD:
1037
1038    absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
1039    absolute-form = absolute-URI
1040    absolute-path = 1*( "/" segment )
1041    asterisk-form = "*"
1042    authority = <authority, see [RFC3986], Section 3.2>
1043    authority-form = authority
1044 
1045    chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
1046    chunk-data = 1*OCTET
1047    chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
1048    chunk-ext-name = token
1049    chunk-ext-val = token / quoted-string
1050    chunk-size = 1*HEXDIG
1051    chunked-body = *chunk last-chunk trailer-part CRLF
1052    comment = "(" *( ctext / quoted-pair / comment ) ")"
1053    connection-option = token
1054    ctext = HTAB / SP / %x21-27 ; '!'-'''
1055     / %x2A-5B ; '*'-'['
1056     / %x5D-7E ; ']'-'~'
1057     / obs-text
1058
1059NEW:
1060
1061    absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
1062    absolute-form = absolute-URI
1063    absolute-path = 1*( "/" segment )
1064    asterisk-form = "*"
1065    authority = <authority, see [RFC3986], Section 3.2>
1066    authority-form = authority
1067    chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
1068    chunk-data = 1*OCTET
1069    chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
1070    chunk-ext-name = token
1071    chunk-ext-val = token / quoted-string
1072    chunk-size = 1*HEXDIG
1073    chunked-body = *chunk last-chunk trailer-part CRLF
1074    comment = "(" *( ctext / quoted-pair / comment ) ")"
1075    connection-option = token
1076    ctext = HTAB / SP / %x21-27 ; '!'-'''
1077     / %x2A-5B ; '*'-'['
1078     / %x5D-7E ; ']'-'~'
1079     / obs-text
1080
1081
1082Appendix B., paragraph 22:
1083OLD:
1084
1085    A
1086       absolute-form (of request-target)  41
1087       accelerator  10
1088       application/http Media Type  62
1089       asterisk-form (of request-target)  42
1090       authoritative response  66
1091       authority-form (of request-target)  42
1092
1093NEW:
1094
1095    A
1096       absolute-form (of request-target)  42
1097       accelerator  10
1098       application/http Media Type  63
1099       asterisk-form (of request-target)  43
1100       authoritative response  67
1101       authority-form (of request-target)  42-43
1102
1103
1104Appendix B., paragraph 24:
1105OLD:
1106
1107    C
1108       cache  11
1109       cacheable  11
1110       captive portal  11
1111       chunked (Coding Format)  28, 31, 35
1112       client  7
1113       close  50, 55
1114       compress (Coding Format)  38
1115       connection  7
1116       Connection header field  50, 55
1117       Content-Length header field  29
1118
1119NEW:
1120
1121    C
1122       cache  11
1123       cacheable  12
1124       captive portal  11
1125       chunked (Coding Format)  28, 32, 36
1126       client  7
1127       close  51, 56
1128       compress (Coding Format)  38
1129       connection  7
1130       Connection header field  51, 56
1131       Content-Length header field  30
1132
1133
1134Appendix B., paragraph 25:
1135OLD:
1136
1137    D
1138       deflate (Coding Format)  38
1139       Delimiters  26
1140       downstream  9
1141
1142NEW:
1143
1144    D
1145       deflate (Coding Format)  38
1146       Delimiters  27
1147       downstream  10
1148
1149
1150Appendix B., paragraph 26:
1151OLD:
1152
1153    E
1154       effective request URI  44
1155
1156NEW:
1157
1158    E
1159       effective request URI  45
1160
1161
1162Appendix B., paragraph 27:
1163OLD:
1164
1165    G
1166       gateway  10
1167       Grammar
1168          absolute-form  41
1169          absolute-path  16
1170          absolute-URI  16
1171          ALPHA  6
1172          asterisk-form  41-42
1173          authority  16
1174          authority-form  41-42
1175          BWS  24
1176          chunk  35
1177          chunk-data  35
1178          chunk-ext  35-36
1179          chunk-ext-name  36
1180          chunk-ext-val  36
1181          chunk-size  35
1182          chunked-body  35-36
1183          comment  27
1184          Connection  50
1185          connection-option  50
1186          Content-Length  29
1187          CR  6
1188          CRLF  6
1189          ctext  27
1190          CTL  6
1191          DIGIT  6
1192          DQUOTE  6
1193          field-content  22
1194          field-name  22, 39
1195          field-value  22
1196          field-vchar  22
1197          fragment  16
1198          header-field  22, 36
1199          HEXDIG  6
1200          Host  43
1201          HTAB  6
1202          HTTP-message  19
1203          HTTP-name  13
1204          http-URI  16
1205          HTTP-version  13
1206          https-URI  18
1207          last-chunk  35
1208          LF  6
1209          message-body  27
1210          method  21
1211          obs-fold  22
1212          obs-text  27
1213          OCTET  6
1214          origin-form  41
1215          OWS  24
1216          partial-URI  16
1217          port  16
1218          protocol-name  47
1219          protocol-version  47
1220          pseudonym  47
1221          qdtext  27
1222          query  16
1223          quoted-pair  27
1224          quoted-string  27
1225          rank  38
1226          reason-phrase  22
1227          received-by  47
1228          received-protocol  47
1229          request-line  21
1230          request-target  41
1231          RWS  24
1232          scheme  16
1233          segment  16
1234          SP  6
1235          start-line  20
1236          status-code  22
1237          status-line  22
1238          t-codings  38
1239          t-ranking  38
1240          tchar  26
1241          TE  38
1242          token  26
1243          Trailer  39
1244          trailer-part  35-36
1245          transfer-coding  35
1246          Transfer-Encoding  28
1247          transfer-extension  35
1248          transfer-parameter  35
1249          Upgrade  56
1250          uri-host  16
1251          URI-reference  16
1252          VCHAR  6
1253          Via  47
1254 
1255       gzip (Coding Format)  38
1256
1257NEW:
1258
1259    G
1260       gateway  10
1261       Grammar
1262          absolute-form  42
1263          absolute-path  16
1264          absolute-URI  16
1265          ALPHA  6
1266          asterisk-form  41, 43
1267          authority  16
1268          authority-form  42-43
1269          BWS  25
1270          chunk  36
1271          chunk-data  36
1272          chunk-ext  36
1273          chunk-ext-name  36
1274          chunk-ext-val  36
1275          chunk-size  36
1276          chunked-body  36
1277          comment  27
1278          Connection  51
1279          connection-option  51
1280          Content-Length  30
1281          CR  6
1282          CRLF  6
1283          ctext  27
1284          CTL  6
1285          DIGIT  6
1286          DQUOTE  6
1287          field-content  23
1288          field-name  23, 40
1289          field-value  23
1290          field-vchar  23
1291          fragment  16
1292          header-field  23, 37
1293          HEXDIG  6
1294          Host  44
1295          HTAB  6
1296          HTTP-message  19
1297          HTTP-name  14
1298          http-URI  17
1299          HTTP-version  14
1300          https-URI  18
1301          last-chunk  36
1302          LF  6
1303          message-body  28
1304          method  21
1305          obs-fold  23
1306          obs-text  27
1307          OCTET  6
1308          origin-form  42
1309          OWS  25
1310          partial-URI  16
1311          port  16
1312          protocol-name  47
1313          protocol-version  47
1314          pseudonym  47
1315          qdtext  27
1316          query  16
1317          quoted-pair  27
1318          quoted-string  27
1319          rank  39
1320          reason-phrase  22
1321          received-by  47
1322          received-protocol  47
1323          request-line  21
1324          request-target  41
1325          RWS  25
1326          scheme  16
1327          segment  16
1328          SP  6
1329          start-line  21
1330          status-code  22
1331          status-line  22
1332          t-codings  39
1333          t-ranking  39
1334          tchar  27
1335          TE  39
1336          token  27
1337          Trailer  40
1338          trailer-part  37
1339          transfer-coding  35
1340          Transfer-Encoding  28
1341          transfer-extension  35
1342          transfer-parameter  35
1343          Upgrade  57
1344          uri-host  16
1345          URI-reference  16
1346          VCHAR  6
1347          Via  47
1348       gzip (Coding Format)  39
1349
1350
1351Appendix B., paragraph 28:
1352OLD:
1353
1354    H
1355       header field  19
1356       header section  19
1357       headers  19
1358       Host header field  43
1359       http URI scheme  16
1360       https URI scheme  18
1361 
1362    I
1363       inbound  9
1364       interception proxy  11
1365       intermediary  9
1366
1367NEW:
1368
1369    H
1370       header field  19
1371       header section  19
1372       headers  19
1373       Host header field  44
1374       http URI scheme  17
1375       https URI scheme  17
1376    I
1377       inbound  9
1378       interception proxy  11
1379       intermediary  9
1380
1381
1382Appendix B., paragraph 29:
1383OLD:
1384
1385    M
1386       Media Type
1387          application/http  62
1388          message/http  61
1389       message  7
1390       message/http Media Type  61
1391       method  21
1392
1393NEW:
1394
1395    M
1396       Media Type
1397          application/http  63
1398          message/http  62
1399       message  7
1400       message/http Media Type  62
1401       method  21
1402
1403
1404Appendix B., paragraph 30:
1405OLD:
1406
1407    N
1408       non-transforming proxy  48
1409
1410NEW:
1411
1412    N
1413       non-transforming proxy  49
1414
1415
1416Appendix B., paragraph 31:
1417OLD:
1418
1419    O
1420       origin server  7
1421       origin-form (of request-target)  41
1422       outbound  9
1423
1424NEW:
1425
1426    O
1427       origin server  7
1428       origin-form (of request-target)  42
1429       outbound  10
1430
1431
1432Appendix B., paragraph 32:
1433OLD:
1434
1435    P
1436       phishing  66
1437       proxy  10
1438
1439NEW:
1440
1441    P
1442       phishing  67
1443       proxy  10
1444
1445
1446Appendix B., paragraph 35:
1447OLD:
1448
1449    T
1450       target resource  40
1451       target URI  40
1452       TE header field  38
1453       Trailer header field  39
1454       Transfer-Encoding header field  28
1455       transforming proxy  48
1456       transparent proxy  11
1457       tunnel  10
1458
1459NEW:
1460
1461    T
1462       target resource  40
1463       target URI  40
1464       TE header field  39
1465       Trailer header field  40
1466       Transfer-Encoding header field  28
1467       transforming proxy  49
1468       transparent proxy  11
1469       tunnel  10
1470
1471
1472Appendix B., paragraph 36:
1473OLD:
1474
1475    U
1476       Upgrade header field  56
1477       upstream  9
1478       URI scheme
1479          http  16
1480          https  18
1481       user agent  7
1482
1483NEW:
1484
1485    U
1486       Upgrade header field  57
1487       upstream  9
1488       URI scheme
1489          http  17
1490          https  17
1491       user agent  7
1492
1493
1494Appendix B., paragraph 37:
1495OLD:
1496
1497    V
1498       Via header field  46
1499
1500NEW:
1501
1502    V
1503       Via header field  47
1504
Note: See TracBrowser for help on using the repository browser.